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and  Agencies  of  the  Department  of  Defense. 


Beneficial  comments  (recommendations,  additions,  deletions) 
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document  should  be  addressed  to.-  Commander,  Hq  ESD/ALBT ,  Hanscom 
AFB,  ka  01731  by  using  the  self-addressed  Standardization  Document 
Improvement  Proposal  ( DD  Form  1426)  appearing  at  the  end  of  this 
document  or  by  letter. 
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FOREWORD 

This  standard  has  been  designed  to  take  advantage  of  current 
technological  advancement  and  management  procedures  m  conducting 
reviews  and  audits. 
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SECTION  i 
SCOPE 

1.1  Purpose .  This  standard  prescribes  the  requirements  lor  the 
conduct-  oT  Technical  Reviews  and  Audits  on  Systems,  Equipments, 
and  Computer  Software. 

1.2  Classif ication.  The  following  technical  reviews  and  audits 
shall"  be  .selected  by  the  program  manager  at  the  appropriate  phase 
of  program  development.  Each  reviev/audit  is  generally  described 
in  Section  3,  Definitions,  and  more  specifically  defined  in  a 
separate  appendix. 

System  Requirements  Review  (SRR) 

System  Design  Review  (SDR) 

Software  Specification  Review  (SSR) 

Preliminary  Design  Review  ( PDR ) 

Critical  Design  Review  (CDR) 

Test  Readiness  Review  (TRR) 

Functional  Configuration  Audit  (FCA) 

Physical  Configuration  Audit  (PCX) 

Formal  Qualification  Review  (FQR) 

Production  Readiness  Review  ( PRR ) 

NOTE:  A  typical  engineering  and  test  flow  relative  to  program 
activities  is  illustrated  in  Figure  I. 

1.3  Applicat ion.  Technical  Reviews  and  .\udits  defined  herein 
shal..  be  conducted  in  accordance  with  this  standard  to  the  extent 
specified  in  the  contract  clauses,  Statement  of  work  (SOW),  and 
the  Contract  Data  Requirements  List.  Guidance  in  applying  this 
standard  is  provided  in  Appendix  J.  The  contracting  agency  shall 
tailor  this  standard  to  require  only  what  is  needed  for  each 
individual  acquisition. 
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SECTION  2 

REFERENCED  DOCUMENTS 

2,1  Reference  documsniis  are  not  included  in  this  document.  The 
Statement  of  work  shall  be  referenced  for  applicable  documents. 

(Copies  of  specifications,  standards,  drawings,  and 
publications  required  by  contractors  in  connection  with 
specific  procurement  functions  should  be  obtained  from  the 
contracting  agency  or  as  directed  by  the  contracting 
officer). 
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SECT I OK  3 
DEFINITIONS 

TECHNICAL  REVIEWS  AND  AUDITS 

3.1  System  Requirements  Review  ( SRR ) .  The  objective  of  this 
review  is  to  ascertain  the  adequacy  of  the  contractor’s  efforts  in 
defining  syutem  requirements.  It  viii  be  conducted  vhen  a 
significant  portion  of  the  system  functional  requirements  has  beer, 
established, 

3.2  System  Design  Review  (SDF. )  .  This  review  shall  be  conducted  to 
evaluate  the  opt imixation,  correlation,  completeness,  and  risks 
associated  with  the  allocated  technical  requirements.  Also 
included  is  a  summary  review  of  the  system  engineering  process 
which  produced  the  allocated  technical  requirements  and  of  the 
engineering  planning  for  the  next  phase  of  effort.  Basic 
manufacturing  considerations  will  be  reviewed  and  planning  for 
production  engineering  in  subsequent  phases  will  be  addressed. 
This  review  will  be  conducted  when  the  system  definition  effort 
has  proceeded  to  the  point  where  system  characteristics  are 
defined  and  the  configuration  items  are  identified. 

3.3  Software  Specif icat ion  Review  (SSR) .  A  review  of  the 
finalized  (HompJter  Software  Cori'tf igurat lorTTtem  (CSCI)  requirements 
and  operational  concept.  The  SSR  is  conducted  when  CSCI 
requirements  heve  been  .sufficiently  defined  to  evaluate  the 
contractor's  responsi veness  to  and  interpretation  of  the  system, 
segment,  or  prime  item  level  requirements.  A  successful  SSR  is 
predicated  upon  the  contracting  agency's  determination  that  the 
Software  Requirements  Specification,  Interface  Requirements 
Spec i f icat ion (s ) ,  and  Operational  Concept  Document  form  a 
sat  isf  ecr.ory  basis  for  proceeding  into  preliminary  software 
design. 

3.4  Preliminary  Design  Kev i ew  ( PDR ) .  This  review  shall  be 
conducted  f  or  each  configuration  item  or  aggregate  of 
configuration  item*  to  (1)  evaluate  the  progress,  technical 
adequacy,  and  risk  resolution  (on  a  technical,  cost,  and  schedule 
basis)  of  the  selected  design  approacn,  (2)  determine  its 
compatibility  with  performance  and  /eng  inhering  speciality 
requirements  of  the  Hardware  Configuration  Item  (HWC1)  development 
specification,  (3)  -evaluate  the  degree  of  -definition  and  assess 
the  technical  risk  associated  with  the  selected  manufacturing 
methods/processes ,  anil  (4)  establish  the  existence  and 
compatibility  of  the  physical  and  functional  interfaces  among  the 
configuration  item  and  other  items  of  equipment,  facilities, 
computer  software,  and  personnel.  For  CSCIs,  this  review  will 
focus  on:  (1)  the  evaluation  of  the  progress,  consistency,  and 
technical  adequacy  of  the  selected  top-level  design  and  test 
approach,  (2)  compatibility  between  software  requirements  and 
preliminary  design,  and  (3)  on  the  preliminary  version  of  the 
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operation  and  support  documents. 


3.5  Critical  Des icn  Review  < CPR ) .  This  review  shall  be  conducted 
for  "“each  canTTgurat ion  item  when  detail  dosign  is  essentially 
complete.  The  purpose  of  this  review  will  be  to  .  (1)  determine 
that  the  detail  design  of  the  configuration  item  under  review 
satisfies  the  performance  and  engineering  specialty  requirements 
of  the  HWCI  development  specifications,  (2)  establish  the  detail 
design  compatibility  among  the  configuration  item  and  other  items 
of  equipment,  facilities,  computer  software  and  personnel,  (3) 
assess  configuration  item  risk  areas  (on  a  technical,  cost,  and 
schedule  basis),  (4)  assess  the  results  of  the  produc ibi 1 i ty 
analyses  conducted  on  system  hardware,  and  (5)  review  tne 
preliminary  hardware  product  specifications.  For  CSCIs.  this 
review  will  focus  on  the  determination  of  the  acceptability  of  the 
detailed  design,  performance,  and  test  character  1st ics  of  the 
design  solution,  and  on  the  adequacy  of  the  Operation  and  support 
documents. 


3 . 6  Test  Read  i  r.css _ ^ _ 

to  determine  whether  the 
to  nssure  that  the  contractor 
Soft  wars  tesi  procedures  art 
software  test 
accompl irhing 


Review  ( TRR ) .  A  review  conducted  for  each  CSCI 
’software  test  procedures  are  complete  and 
is  prepared  for  formal  CSC I  testing, 
evaluated  for  compliance  with 
plans  and  descriptions,  and  for  adequacy  in 
test  requirements.  At  TRR ,  the  contracting  agency 
also  reviews  the  results  of  informal  software  testing  and  any| 
updates  to  the  operation  and  support  documents.  A  successful  TRR 
is  predicated  on  the  contracting  agency’s  determination  rhat  the 
software  test  procedures  and  informal  test  results  form  a 
satisfactory  basis  for  proceeding  into  formal  CSCI  testing. 


3.7  Funet ional  Configuration  Aud i t  ( FCA ? ,  A  formal  audit  to 
validate'  that  ’ the  development  of  a  configuration  item  has  been 
completed  sat  is f actor i 1 y  and  that  tne  configuration  item  has 
achieved  the  performance  and  functional  charact er ist i cs  specified 
in  the  functional  or  allocated  configuration  identification.  In 
addition,  the  completed  operation  and  support  documents  shall  be 
reviewed. 

3.8  Physical  Co nf iuuration  Audit  ( PC A ) .  A  technical  examination 
of  a  designated  "conf iguret ion  item  to  verify  that  '  the 
configuration  item  "As  Built"  conforms  to  the  technical 
documentation  which  defines  the  configuration  item. 


3.9  Formal  Qual i f icat ion  Review  ( FQR ) .  The  test,  inspection,  or 
analytical  process  by  which  a  group  of  configuration  items 
comprising  the  system  are  verified  to  have  met  specific 
contracting  agency  contractual  performance  requirements 
(specifications  or  equivalent).  This  review  does  not  apply  to 
hardware  or  software  requirements  verified  at  FCA  for  the 
individual  configuration  item. 
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3.10  Product  ion  Readiness  Review  (P  RJR)  .  This  review  is  intended 
to  determine  tKe  status  of  completion  of  the  specific  actions 
which  must  be  sat isfactor i ly  accomplished  prior  to  executing  a 
production  go-ahead  decision.  The  review  is  accomplished  in  an 
incremental  fashion  during  the  Full-Scale  Development  phase, 
usually  two  initial  reviews  and  one  final  review  to  assess  the 
risk  in  exercising  the  production  go-ahead  decision.  In  its 
earlier  stages  the  PRR  concerns  itself  with  gross  level 
manufacturing  concerns  such  as  the  need  for  identifying  high 
risk/low  yield  manufacturing  processes  or  materials  or  the 
requirement  for  manufacturing  development  effort  to  satisfy  design 
requirements.  The  reviews  become  mere  refined  as  the  design 
matures,  dealing  with  such  concerns  as  production  planning, 
facilities,  allocation,  incorporation  of  producibility-oriented 
changes,  identification  and  fabrication  of  tools/test  equipment, 
long  lead  item  acquisition  etc.  Timing  of  the  incremental  PRRs  is 
a  function  of  program  posture  and  is  not  specifically  locked  in  to 
other  reviews. 


OTHER  DEFINITIONS 

3.11  For  further  guidance  on  cost  terminology  see 
edition  of  DODI  5000.33,  Uniform  Budget/Cost 
Definitions. 


the  latest 
Terns  and 


3.12  New  titles  are  being  phased  in  for  the  levels  of  maintenance. 
They  are  (with  their  former  terms);  On  Equipment 
(Organizational),  Off  Equipment  -  On  Site  (  Intermediate ) ,  Off 
Equipment  -  Off  Site  (Depot).  See  the  latest  edition  of  AFR 

Policies,  Objectives,  and 


66-14,  Equipment 
Responsibi 1 i t ies . 


Maintenance 


3.13  For  definitions  of  the  various  levels  of  repair,  see  the 
latest  edition  of  MIL-STD-280A,  Definition  of  Item  bevels.  Item 
Exchangeability,  Models,  and  Related  Terms. 

3.14  Configuration  item.  Hardware  or  software,  or  an  aggregation 
of  both,  which  is  designated  by  the  contracting  agency  for 
configuration  management. 
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SECTION  4 

GENERAL  REQUIREMENTS 

4.1  Contractor  Participation  and  Responsibilities.  The  contractor 
shall  Se  Tes ponsT5Te^”7orr,,~  conducting  "the  Technical  Reviews  and 
Audits  in  accordance  with  the  following  requirements  except  as 
amended  by  the  contract. 

4.1.1  Subcont  ractors  and  Suppliers .  The  contractor  shall  be 
responsible  for  insuring  that  subcontractors,  vendors,  and 
suppliers  participate  in  formal  Reviews/Audits,  as  appropriate. 

« 

4.1.2  Location ,  Unless  otherwise  specified  in'  the  Statement  of 
Work,  the  Reviews /Audits  shall  be  conducted  at  the  contractor's 
facility  or  at  a  designated  subcontractor  facility,  if  approved  by 
the  contracting  agency.  Accordingly,  the  contractor  shall  be 
required  to  provide  the  necessary  resources  and  material  to 
perform  the  Review/Audit  effectively.  This  includes  the  following 
items  to  the  extent  appropriate  for  the  type  and  scope  of 
Review/Audit  required  by  the  contract: 

a.  Meeting  agenda/plans 

b.  Conference  room(s) 

c.  Applicable  system  engineering  data,  specifications, 

drawings,  manuals,  schedules,  and  design  and  test  data 

d.  Specialty  study  results 

e.  Trade  study  results 

f.  Risk  analysis  results 

g.  Mockups ,  breadboards,  in-process  hardware,  and  finished 

hardware 

h.  Test  methods  and  data 

i.  Meeting  minutes 

4.1.3  Contractor  Requirements.  The  contractor  shall  be 
responsible  ~~?or~  establishing  the  time,  place  and  agenda  for  each 
Revicv/Audit  in  consonance  with  the  master  milestone  schedule, 
subject,  to  coordincidt  ion  with  the  contracting  agency.  This  should 
be  accomplished  sufficiently  in  advance  of  each  Reviev/Audit  to 
allow  adequate  preparation  for  the  meeting  by  both  the  contractor 
and  the  contracting  agency  (see  6.2).  in  addition,  the  contractor 
shall  : 

4. 1.3.1  insure  that  each  Review/Audit  schedule  is  compatible  with 
the  availability  of  the  necessary  information  and  contract 
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articles,  e.g.,  system  engineering  data,  trade  study  resultsJ^|F 
producibil ity  analysis  results,  risk  analysis  results, 
specifications,  manuals,  drawings,  reports,  hardware,  software,  or 
raockups . 

4. 1.3. 2  Prepare  for  each  Review/Audit  in  sufficient  detail 
consistent  with  the  scope  and  magnitude  of  the  Review/Audit. 

4. 1.3. 3  Designate  a  Co-Chairperson  for  each  iieviev/Aud  i  t , 
participating  contractor  and  subcontractor  personnel  or  those 
chosen  to  make  presentat ions  shall  be  prepared  to  discuss  in 
technical  detail  any  of  the  presented  material  within  the  scope  of 
the  review. 

4. 1.3.4  Provide  a  stenograph er  or  other  acceptable  method  to 

record  inputs  to  official  meeting  minutes.  Minutes  shall  be 

recorded  only  as  dictated  by  either  Co-Chairperson  and  shall 
consist  of  significant  questions  and  answers,  action  items, 
deviations,  conclusions,  recommended  courses  of  action  resulting 
from  presentations  or  discussions.  Conclusions  from  discussions 
conducted  during  side  meetings  shall  be  summarized  in  the  main 
meeting  at  an  appointed  time,  and  appropriate  comments  shall  be 
read  into  the  official  minutes.  Recommendations  not  accepted 
should  also  be  recorded  together  with  the  reason  for 

non-acceptance.  The  minutes  of  each  daily  session  shall  be 
available  for  review  by  both  the  contractor  and  contracting  ag*ncj|j^ 
personnel  at  the  conclusion  u  f  caCu  day's  SSSSiOn  ( 3t-€  £> ,  2  ,  . 

4. 1.3. 5  Clearly  record  all  action  items  in  the  minutes  and 
identify  whether  contracting  agency  and/or  contractor  action  is 
required  for  its  resolution.  (See  Figure  2  for  Sample  Action  Item 
Form )  . 

4.  1.3. 6  Publish  and  distribute  official  minutes. 

4 . 2  Contract i nq  Agency  Part i c ipat ion. 

4.2.1  Serves  as  Co-Chairperson. 

4.2.2  Provides  the  name,  organization,  and  security  clearance  of 
each  participating  individual  to  the  contractor  prior  to  each 
Review/Audi t . 

4.2.3  Revievs  the  daily  minutes  and  ensures  that  they  reflect  all 
significant  contracting  agency  inputs, 

4.2.4  Provides  formal  acknowledgement  to  the  contractor  of  the 
accompli shroent  of  each  Review/ Audit  after  receipt  of  Review/Audit 
minutes  (see  6.1).  The  contracting  agency  establishes  the 
adequacy  of  the  contractor's  review  performance  by  notification 
of : 

a.  Approval  —  to  indicate  that  the  review  was  sat  isfactori^^ 


i  a  , 


r  .  p..  p  r 


MIL-STD-152IB 


1 


cotr.pj.vtad. 

b.  Contingent  approval  —  to  indicate  that  the  review  is  not 
considered  accomplished  until  the  satisfactory  completion  of 
resultant  action  items. 

c.  Disapproval  —  to  indicate  that  the  review  was  seriously 
inadequate. 

4.3  Sample  Forms .  A  sample  action  item  form  and  sample 
cert iTTcatlon  ‘attachment  are  provided  for  guidance  purposes  (see 
Figures  2 ,  3  and  4 ) . 
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SECTION  5 

DETAILED  REQUIREMENTS 

5.1  The  appropriate  Reviews  or  Audits  will  be  conducted  as 
specified  in  the  following  appendices  (as  selected  and/or  modified 
in  the  contract ) : 

5.1.1  System  Requirements  Review.  See  Appendix  A. 

5.1.2  System  Design  Review.  See  Appendix  B. 

5.1.3  Software  Specification  Review.  See  Appendix  C. 

5.1.4  Preliminary  Design  Review.  See  Appendix  D. 

5.1.5  Critical  Design  Review.  See  Appendix  E. 

5.1.6  Test  Readiness  Review.  See  Appendix  F. 

5.1.7  Functional  Con f igur at  ion  Audit.  See  Appendix  G. 

5.1.8  Physical  Configuration  Audit.  See  Appendix  H. 

5.1.9  Formal  Qualification  Review.  See  Appendix  I. 

5.1.10  Application  Guide  For  Tailoring  MIL-STD-1521 .  „  See 

Appendix  J. 

,5.1.11  Production  Readiness  Review.  See  Appendix  K. 
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SECTION  6 
NOTES 

6.1  Intended  use.  This  standard  prescribes  the  requirements  for 
conduct ing  Technical  Reviews  and  Audits  on  Systems,  Equipments, 
and  Computer  Software.  Official  acknowledgement  by  the 
contracting  agency  of  the  accomplishment  of  a  Review/Audit  is  r.ot 
to  be  interpreted  as  approval  of  statements  made  in  the  minutes  or 
of  matters  discussed  at  the  Review/Audit  and  does  not  relieve  the 
contractor  from  requirements  which  are  a  part  of  the  contract. 

6.2  Data  requirements  1 ist  and  cross  reference .  When  this 
standard  is  used  in  an  acquisition'  which  incorporates  a  DD  Form 
1423,  Contract  Date  Requirements  List  (CDRL),  the  data 
requirements  identified  below  shall  be  developed  as  specified  by 
an  approved  Data  Item  Description  (DD  Form  1664)  and  delivered  in 
accordance  with  the  approved  CDRL  incorporated  into  the  contract, 
when  the  provisions  of  the  DOD  FAR  clause  on  data  requirements 
(currently  DOD  FAR  Supplement  52.227-7031)  are  invoked  and  the  DD 
Form  1423  is  not  used,  the  data  specifieo  below  shall  be  delivered 
Dy  the  contractor  in  accordance  with  the  contract  or  purchase 
order  requirements.  Deliverable  data  required  by  this  standard  is 
cited  in  the  following  paragraphs. 

Paragraph  No.  Data  Requirement  Title  Applicable  DID  No . 

4.1.3  Conference  Agenda  DI-A*7O08 

4.1. 3.4  Conference  Minutes  DI-A-70B9 


(Data  item  descriptions  related  to  this  standard,  and  identified 
in  section  6  will  be  approved  end  listed  as  such  in  DOD 
5000. 19-L.,  Vol.  II,  AMSDL.  Copies  of  data  item  descriptions 
required  by  the  contractors  in  connection  with  specific 
acquisition  functions  should  be  obtained  from  the  Navel 
Publications  and  Forms  Center  or  as  directed  by  the  contracting 
off icer .  ) 

6.3  Changes  f rom  previous  issue ,  Asterisks  or  vertical  lines  are 
not  used  "in  this  revision  to  identify  changes  with  respect  to  the 
previous  issue  due  to  the  extensiveness  of  the  changes. 
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FIGURE  1 .  Engineering  und  T eel  Flow. 
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10.  System  Requirements  Review  ( SRR) . 

10.1  General .  The  SRRs  are  normally  conducted  during  the  system 

Concept  Exploration  or  Demonstration  and  validation  phase.  Such 
reviews  may  oe  conducted  at  any  time  but  normally  will  be 
conducted  after  the  accomplishment  of  functional  analysis  and 
preliminary  requirements  allocation  (to 

operational/maintenance/training  Hardware  Configuration  Items 
(HWCIs) ,  Computer  Software  Configuration  Items  (CSCIs),  facility 
configuration  items,  manufacturing  considerations,  personnel  and 
human  factors)  to  determine  initial  direction  and  progress  of  the 
contractor's  System  Engineering  Management  effort  and  his 
convergence  upon  an  optimum  and  complete  configuration. 

10.2  Purpose.  The  total  System  Engineering  Management  activity 
and  its  output  shall  be  reviewed  for  responsiveness  to  the 
Statement  of  Work  and  system/segment  requirements.  Contracting 
agency  direction  to  the  contractor  will  be  provided,  as  necessary, 
for  continuing  the  technical  program  and  system  optimization. 

10.3  Items  to  be  Reviewed.  Representative  items  to  be  reviewed 
include  the  results  of  the  following,  as  appropriate: 

a.  Mission  and  Requirements  Analysis 

b.  Functional  Flow  Analysis 

c.  Preliminary  Requirements  Allocation 

d.  System/Cost  Effectiveness  Analysis 

e.  Trade  Studies  (e.g.,  addressing  system  functions  in 
hardware/f irmvare/sof tvare ) 

f.  Synthesis 

g.  Logistics  Support  Analysis 

h.  Specialty  Discipline  Studies  (i.e.,  hardware  and  software 

reliability  analysis,  Hsalntainabi lity  -analysis,  armament 
integration,  electromagnetic  compatibility, 

isurv ivabi  1 1 uy/vulner.abi  1  i ty  (including  nuclear),  inspection 
methods/techniques  analysis,  energy  management, 

environmental  cons iderat ions ) . 

i.  System  Interface  Studies 

j.  Generation  of  Specifications 

k.  Program  Risk  Analysis 

l.  Integrated  Test  Planning 
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a.  producibility  Analysis  Plans  1 

n.  Technical  Perforaance  Measurement  Planning 

o.  Engineering  Integration 

p.  Data  Management  Plans 

q.  Configuration  Management  Plans 

r.  System  Safety 

s.  Human  Factors  Analysis 

t.  value  Engineering  Studies 

u. .  Life  Cycle  Cost  Analysis 

v.  Preliminary  Manufacturing  Plans 

v.  Manpower  Requi rements/Personnel  Analysis 
x.  Milestone  Schedules 

10.3.1  The  contractor  shall  describe  his  progress  and  problems  in: 

10.3.1.1  Risk  identification  and  risk  .ranking  (the 
interrelationship  among  system  ef f ect i veness  analysis,  technical 
performance  measurement,  intended  manufacturing  methods,  and  costs 
shall  be  discussed,  as  appropriate). 

10.3.1.2  Risk  avoidance/reduction  and  control  (the 

interrelationships  with  trade-off  studies,  test  planning,  hardware 
proofing,  and  technical  performance  measurement  shall  be 
discussed,  as  appropriate). 

10.3.1.3  Significant  trade-offs  among  stated  system/segment 

specification  requi rements/constra i nts  and  resulting  engineering 
design  requirements/constra ints ,  manufacturing  methods/process 
constraints,  and  logistic/cost  of  ownership 

requirements/constraints  and  unit  production  cost/design-to-cost 
objectives, 

10.3.1.4  Identifying  computer  resources  of  the  system  and 
partitioning  the  system  into  KWCls  and  CSCIs.  Include  any 
trade-off  studies  conducted  to  evaluate  alternative  approaches  and 
methods  for  meeting  operational  needs  and  to  determine  the  effects 
of  constraints  on  the  system.  Also  include  any  evaluations  of 
logistics,  technology,  cost,  schedule,  resource  limitations, 
intelligence  estimates,  etc.,  mad1?  to  determine  their  impact  on 
the  system.  In  addition,  address  the  following  specific  tradeoffs 
related  to  computer  resources: 
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a.  Candidate  programming  languages  and  computer  architectures 
evaluated  in  light  of  DoD  requirements  for  approved  higher 
order  languages  and  standard  instruction  set  architectures. 

b.  Alternative  approaches  evaluated  for  implementing  security 
requirements.  H  an  approach  has  been  selected,  discuss  hov 
it  is  the  most  economical  balance  of  elements  which  meet  the 
total  system  requi remonts. 

c.  Alternative  approaches  identified  for  achieving  the 

operational  and  support  concepts,  and,  for  joint  service 
programs,  opportunities  for  interservice  support. 

10.1.1.5  Producibil ity  and  manufacturing  considerations  which 
could  impact  the  program  decision  such  as  critical  components, 
materials  and  processes,  tooling  and  test  equipment  development, 
production  testing  methods,  long  lead  items,  and 
fac il i t ies/personnel/ski 11s  requirements . 

10.3.1.6  Significant  hazard  consideration  should  be  made  here  to 
develop  requirements  and  constraints  to  eliminate  or  control  these 
system  associated  hazards. 

10.3.2  Information  which  the  contractor  identifies  as  being  useful 
to  his  analysis  and  available  through  the  contracting  agency  shall 
be  requested  prior  to  this  review  (e.g,,  prior  studies, 
operational/support  factors,  cost  factors,  safety  data,  test 
plants? ,  etc.).  A  separate  SRR  may  be  conducted  for  each  of  the 
operational  support  subsystems  depending  upon  the  nature  and 
complexity  of  the  program. 

10.4  Post  Review  Act  ion .  After  completing  the  SRR,  the  contractor 
shall  publ ish  and  distr ibute  copies  o t  Review  minutes.  The 
contracting  agency  officially  acknowledges  completion  of  the  SRR 
as  indicated  in  paragraph  4.2.4. 
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20.  System  Design  Review  ( SDR) . 


20.1  General .  The  SDR  shall  be  conducted  to  evaluate  the 

opt imi ration ,  traceability,  correlation,  completeness,  and  the 
risk  of  the  allocated  requirements,  including  the  corresponding 
test  requirements  in  fulfilling  the  system/segment  requirements 
(the  functional  baseline).  The  review  encompasses  the  total 
system  requirements,  i.e.,  operat ions/maintenance/test/training 
hardware,  computer  software,  facilities,  personnel,  preliminary 
logistic  support  considerations.  Also  included  stall  be  a  summary 
review  of  the  System  Engineering  Management  Activities  (e.g., 
mission  and  requirements  analysis,  functional  analysis, 

requirements  allocation,  manufacturing  methods/process  selection, 
program  risK  analysis,  systea/cost  effectiveness  analysis, 

logistics  support  analysis,  trade  studies,  intra-  and  inter- 
systeu  interface  studies.  integrated  test  planning,  specialty 
discipline  studies,  and  Configuration  Management)  which  produced 
the  above  system  definition  products.  A  technical  understanding 
shall  be  reached  on  the  validity  and  the  degree  of  completeness  of 
the  following  information: 

a.  System/Segment  Spec i f icat ion 

b.  The  engineering  design/cost  of  the  system  (see  Section  3, 
Definitions). 

e.  Preliminary  Operational  Concept  Document 

d.  Preliminary  Software  Requirements  Specification 

e.  Preliminary  Interface  Requirements  Spsc i f icat ion ( s ) 

f.  As  appropriate: 

(1)  Prime  Item  Development  Specification 

(2)  Critical  Item  Development  Specification 

20*2  Purpose .  An  SDR  shall  be  conducted  as  the  final  review  prior 
to  the  suBmittal  of  the  Demonstration  and  Validation  .Phase 
products  or  as  the  initial  Full  Scale  Development  Review  for 
systems  not  requiring  a  formal  Demonstration  and  Validation  Phase 
but  sufficiently  complex  to  warrant  the  formal  assessment  of  the 
allocated  requirements  (and  the  basis  of  tnese  requirements) 
before  proceeding  with  the  preliminary  design  of  HWCIs  or  the 
detailed  requirements  analysis  for  CSCIs.  The  SDR  is  primarily 
concerned  with  the  overall  review  of  the  operat ionai/support 
requirements  (i.e.,  the  mission  requirements),  updated/completed 
System/Segment  Specification  requirements ,  allocated  performance 
requirements,  programming  and  manufacturing 

methods/processes/planning,  and  the  accomplishment  of  the  System 
Engineering  Management  activities  to  insure  that  the  definition 
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effort  products  ere  necessary  and  sufficient.  The  purposes  of  the 
SDR  are  to: 

20.2.1  Insure  that  the  updated/ccmpleted  System/Segment 
Specification  is  adequate  end  cost  effective  in  satisfying 
validated  mission  requirements. 

20.2.2  Insure  that  the  allocated  requirements  represent  a  complete 
and  optimal  synthesis  of  the  system  requirements. 

20.2.3  Insure  that  the  technical  program  risks  are  identified, 
ranked,  avoided,  and  reduced  through: 

a.  Adequate  trade-offs  (particularly  for  sensitive  mission 
requirements  versus  engineering  realism  and  manufacturing 
feasibility  to  satisfy  the  anticipated  production  quantities 
of  corresponding  performance  requ i renents ) ; 

fc.  Subsystem/component  hardware  proofing,* 

c.  A  responsive  test  program:  and 

d.  Implementation  of  comprehensive  engineering  disciplines 

(e.g.,  worst  case  analysis,  failure  mode  and  effectjgg^ 

analysis,  maintainability  analysis,  prc*ducibi i ity  dnalyslfiSn 
and  standardisation.) 


20.2.4  Identify  hov  the  final  combination  of  operations, 
manufacturing,  maintenance,  logistics  and  test  end  activation 
requirements  have  affected  overall  program  concepts;  quantities 
and  types  of  equipment,  unit  product  cost  (see  Section  3, 
Definitions,  paragraph  3.11),  computer  software,  personnel,  and 
facilities. 


20. 2. S  Insure  that  a  technical  understanding  of  requirements  has 
been  reached  and  technical  direction  is  provided  to  the 
contractor. 


20.3  I  terns  to  be  Reviewed.  The  SDR  shall  include  a  review  of 
following  items,  as  appropriate: 

20.3.1  System  Engineering  Management  Activities,  e.g.: 
a.  Mission  and  Requirements  Analysis 
to.  Functional  Analysis 

c.  Requirements  Allocation 

d.  System/Cost  Effectiveness 

e.  Synthesis 
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f.  Survivebi.lity/Vulnerability  (including  nuclear) 

g.  Reliability/Maintainability/Availability  (R/M/A) 

h.  Electromagnetic  Compatibility 

i.  Logistics  Support  Analysis  (to  address,  as  appropriate, 
integrated  logistics  support  including  logistics  support 
concept,  maintenance,  supply,  software  support  facilities, 
etc. ) 

j .  System  Safety  (emphasis  shall  be  placed  on  system  hazard 
analysis  and  identification  of  safety  test  requirements) 

k.  Security 

l .  Human  Factors 

m.  Transportabi 1 i ty  (including  Packaging  and  Handling) 

n.  System  Mass  Properties 
a,  Standardization. 

p.  Electronic  warfare 

q.  Value  Engineering 

r.  System  Growth  Capability 

s.  Program  Risk  Analysis 

t.  Technical  Performance  Measurement  Planninq 

u.  Producibility  Analysis  and  Manufacturing 

v.  Life  Cycle  Cost/Design  to  Cost  Goals 

w.  Quality  Assurance  Program 

x.  Environmental  Conditions  (Temperature,  vibration.  Shock, 
Humidity,  etc. ) 

y.  Training  and  Training  Support 

z.  Milestone  Schedules 

aa.  Software  Development  Procedures 
20.3.2  Results  of  significant  trade  studies,  for  example: 

•a.  Sensitivity  of  selected  "Bission  requirements  versus 
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realistic  performance  parameters  and  cost  estimates. 

b.  Operations  design  versus  maintenance  design 

c.  System  centralization  versus  decentralization 

d.  Automated  versus  manual  operation 

e.  Heliabi li ty/Msintainabili ty/Avai labi 1 Lty 

f.  Commercially  available  items  versus  new  developments 

g.  National  Stock  Number  (NSN)  itetes  versus  new  development 

h.  Testability  trade  studies  (Allocation  of  fault 
detection/isolation  capabilities  between  elements  of 
built-in  test,  on  board/on-site  fault  detect  ion/ 1 solat ion 
subsystems,  separate  support  equipment,  and  manual 
procedures' 

i.  Size  and  weight 

j.  Desired  propagation  characteristics  versus  reduction  in 

interference  to  other  systems  (optimum  selection  of 
frequencies)  alfe 

k.  Performance/iogis.tics  trade  studies 

l.  Life  cycle  cost  reduction  for  different  computer  programming 
languages 

m.  Functional  allocation  between  hardware,  software,  firmware 
and  personnel/procedures 

n.  Life  Cycle  Cost/system  performance  trade  studies  to  include 
sensitivity  of  performance  parameters  to  cost. 

o.  Sensitivity  of  performance  parameters  versus  cost 

p.  Cost  versus  performance 

q.  Design  versus  manuf octur ing  consideration 

r.  Make  versus  buy 

s.  Software  development  schedule 

0.3.3  Updated  design  requirements  for  operac ions/maintenance 
unctions  and  items. 


20.3.4  Updated  requirements  for  manufacturing  methods 

processes. 
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20.1*.  5  ipdated  operations/maintenance  requirements  for  facilities. 

20.3.6  Updated  requirements  for  operations/maintenance  personnel 
and  training. 

20.3.7  Specific  actions  to  be  performed  include  evaluations  of: 

a.  System  design  feasibility  and  system/coat  effectiveness 

fc.  Capability  of  the  selected  configuration  to  meet 
requirements  of  the  Sys*«m/Segment  Specification 

c.  Allocations  of  system  requirements  to 

subsystems/conf iguration  items 

d.  Use  of  commercially  available  and  standard  parts 

e.  Allocated  inter-  and  intra-  system  interface  requirements 

f.  Size,  weight,  and  configuration  of  HWCls  te>  permit 
eccnomical  and  eifective  transportat ion ,  packaging,  and 
handling  consistent  with  applicable  specifications  and 
s  wandards 

g.  Specific  design  concepts  which  may  require  development 
toward  rdvancing  the  state-of-the-art 

n.  Specific  subsystems/components  which  may  require  "hardware 
proofing"  and  high-risk  long -lead  time  items 

i.  The  ability  of  inventory  items  to  meet  overall  system 
requirements,  and  their  compatibility  with  configuration 
item  interfaces 

j.  The  planned  system  design  in  view  oi  providing  multi-mode 
functions,  as  applicable 

k.  Considerations  given  to: 

(1)  Interference  caused  by  the  external  environment  to  the 
system  and  the  system  to  the  external  environment. 

(2)  Allocated  p' rfornance  characteristics  of  all  system 
transmitters  and  rtceivcrs  to  identify  potential 
intra-syrtem  electromagnetic  ( EM >  incompatibilities. 

(3)  Non-design,  spurious  and  harmcmc  system  performance 
characteristics  and  their  effect  on  electromagnetic 
environments  cf  operational  deployments. 

l.  value  engineering  studies,  preliminary  Value  Engineering 
Change  Proposals  (VECPs)  and  VECPs  \ as  applicable).' 
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20.3.0  Review  the  Preliminary  Operational 
sections  1.0,  2.0,  3.0,  5.0,  6.0,  and  10 

Specification,  all  available  HWCI  Deve 
preliminary  Software  Requirements,  and 
Specifications  for  format,  content, 
completeness  and  traceabii ity/uorrelat 
mission/support  requirements.  All  entries 
(N/A)"  cr  "to  be  determined  (TBD)"  are  ide 
the  contractor. 


Concept  Document,  and 
.0  of  the  System/ Segment 
lopment  Specifications, 
Interface  Requirements 
technical  adequacy, 
ion  to  the  validated 
marked  "not  applicable 
ntifisd  and  explained  by 


20.3.9  Review  section  4.0  of  the  System/Segrcent  Specification,  all 
available  hardware  Development  Specifications,  and  preliminary 
Software  Requirements  and  Interface  Requirements  Specifications 
for  format.  content,  technical  adequacy,  and  completeness.  All 
available  test  documentation,  including  HWCI /subsystem  and  system 
test  plans,  shall  be  reviewed  to  insure  that  the  proposed  test 
program  satisfies  the  test  requirements  of  section  4.0  of  all 
applicable  specifications.  All  entries  labeled  "not  applicable 
(N/A)"  or  "to  be  determined  ( TBD ) "  in  section  4.0  of  any 
applicable  specification  are  identified  and  explained  by  the 
contractor. 


20.3.10  Review  the  system,  HWCI,  and  CSCI  design  for  interaction, 
with  the  natural  environment.  Tt  any  effect  or  interaction  is 
completely  understood  and  further  gfudy  is  required,  or  it  JIB 
known  but  not  completely  compensated  for  in  the  design,  tn^ 
proposed  method  of  resolution  shall  also  be  reviewed.'  All 
proposed  environmental  tests  shall  be  reviewed  for  compatibility 
with  the  specified  natural  environmental  conditions. 

20.3.11  Maintenance  functions  developed  by  the  contractor  to 
determine  that  support  concepts  are  valid,  technically  feasible, 
and  understood.  In  particular,  attention  is  given  to: 

a.  R/K/A  considerations  in  the  updated  System/Segment 

Specif ication 

b.  Maintenance  design  characte /istics  of  the  system 

c.  Corrective  and  preventive  maintenance  requirements 

d.  Special  equipment,  tools,  or  material  required 

e.  Requirements  or  planning  for  automated  ma intenance  analysis 

f.  Item  Maintenance  Analysis  compatibility  with  required 

maintenance  program  when  weapon  is  deployed 


9- 

h. 


Specific  configuration 
Forms,  procedures,  and 


item  support  requirements 
techniques  for  maintenance  analysis^ 
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i.  Maintenance  related  trade-off  studies  and  findings  (includes 
commercially  available  equipment,  software  fault  diagnostic 
techniques ) 

j.  Logistic  cost  impacts 

k.  Support  procedures  and  tools  for  computer  software  which 
facilitate  software  modification,  improvements,  corrections 
and  updates 

l.  Hardness  critical  items/processes 

20.3.12  System  compliance  with  nuclear,  non-nuclear  and  laser 
hardening  requirements.  High  risk  areas  or  design  concepts 
requiring  possible  advances  of  the  state-of-the-art  as  a  result  of 
survivability  critieria  shall  be  identified,  and  prepared 
approach(es)  to  the  problem  reviewed.  Prepared  test  programs 
shall  be  reviewed  for  sufficiency  and  compatibility  with  the 
specified  threat  environment  and  existing  simulation  test 
facilities. 

20.3.13  The  optimization,  traceability,  completeness,  and  risks 
associated  with  the  allocated  technical  requirements,  and  the 
adequacy  of  allocated  system  requirements  as  a  basis  for 
proceeding  with  the  development  of  hardware  and  software 
configuration  items.  Include  any  available  preliminary  Software 
Requirements  and  Interface  Requirements  Specifications. 

20.3.14  Manufacturing  ( HWCI s  only) . 

20.3.14.1  Production  feasibility  and  risk  analyses  addressed  at 
the  SRB  s^all  be  updated  and  expanded.  This  effort  should  review 
the  progress  made  in  reducing  production  risk  and  evaluate  the 
risk  remaining  for  consideration  in  the  Full  Scale  Development 
Phase.  Estimates  of  cost  and  schedule  impacts  shall  be  updated. 

20.3.14.2  Review  of  the  Production  Capability  Assessment  shall 
include: 

20.3.14.2.1  A  review  of  production  capability  shall  be 
accomplished  which  will  constitute  an  assessment  of  the 
facilities,  materials,  methods,  processes,  equipment  and  skills 
necessary  to  perform  the  full  scale  development  and  production 
efforts.  Identification  of  requirements  to  upgrade  or  develop 
manufacturing  capabilities  shall  be  made.  Requirements  for 
Manufacturing  Technology  (MANTECH )  programs  will  also  be 
identified  as  an  element  of  this  production  assessment. 

20.3.14.3  Present  the  management  controls  and  the 
design/manufacturing  engineering  approach  to  assure  that  the 
equipment  is  producible. 
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20.3.14.4  Present  *  review  of  trade-off  studies  for  desicm 

^  tn*  requirement  for  producibility, 
facilities,  tooling-,  production  test  equipment,  inspection,  and 
capital  equipment  for  intended  production  rates  and  volume 


20.3.14.5 

recommend 

needed. 


The  analysis,  assessments  and  trade-off  studies  should 
any  additional  special  studies  or  development  efforts  as 


20.4  Post  Review  Action.  After  completing 
shall  publish  and distribute  copies  of 
contracting  agency  officially  acknowledges 
as  indicated  in  paragraph  4.2.4. 


the  SDR,  the  contractor 
Review  Minutes.  The 
completion  of  the  S&R 
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3 0 .  Software  Specif i cation  Review  (S3R) . 

30.1  General .  The  SSR  shall  he  a  formal  review  of  ?  CSCl’s 
requirements  as  specified  in  the  Software  Requi rements 
Specification  end  the  Interface  Requirements  Specif icat ion (s) . 
Normally,  it  shall  be  held  after  System  Design  Review  hut  prior  to 
the  start  of  CSCI  preliminary  design.  A  collective  SSR  for  a 
cjroup  of  configuration  items,  treating  eech  configuration  item 
individually,  may  be  held  when  such  an  approach  is  advantageous  to 
the  contracting  agency.  Its  purpose  is  to  establish  the  allocated 
baseline  for  preliminary  CSCI  design  by  demonstrating  to  the 
contracting  agency  the  adequacy  of  the  Software  Requirements 
Specification  (SRS).  Interface  Requirements  Speci f icat ion ( s) 
(IRS),  and  Operational  Concept  Document  (OCD). 

30.2  I  terns  to  be  reviewed .  The  contractor  shall  present  the 
following  items  for  review  by  the  contracting  agency: 

a.  Functional  overview  of  the  CSCI,  including  inputs, 
processing,  and  outputs  of  each  function. 

b.  Overall  CSCI  performance  requi rements ,  including  those  for 
execution  time,  storage  requirements,  and  similar 
constraints. 

c.  Control  flew  and  data  flow  between  each  of  the  software 

functions  that  comprise  the  CSCI. 

d.  All  interface  requirements  between  the  CSCI  and  all  other 

configuration  items  both  internal  and  external  to  the 

system. 

e.  Qualification  requirements  that  identify  applicable  levels 
and  methods  of  testing  for  the  software  requirements  that 
comprise  the  CSCI. 

f.  Any  special  delivery  requirements  for  the  CSCI. 

g.  Quality  factor  requirements?  i.e.,  Correctness,  Reliability, 

Efficiency,  Integrity,  Usability,  Maintainability, 

Testability,  Flexibility,  Portability,  Reusability,  and 

Interoperability. 

h.  Mission  requirements  of  the  system  and  its  associated 
operational  and  support  environments. 

i.  Functions  and  character ist ics  of  the  computer  system  within 
the  overall  system. 

j.  Milestone  schedules. 

k.  Updates  since  the  last  review  to  all  previously  delivered 
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software  related  CDRL  items. 


1.  Any  actions  or  procedures  deviating  from  approved  plans. 

30.3  Post  Review  Action.  After  completing  the  SSR,  the  contractor 
shall  publish  And  distribute  copies  of  Review  Minutes.  The 
contracting  agency  officially  acknowledges  completion  of  the  SSR 
as  indicated  in  paragraph  4.2.4. 

30.3.1  The  accomplishment  of  the  SSR  shall  be  recorded  on  the 
configuration  item  Development  Record  by  the  contractor  (see 
MIL-STD-483,  Appendix  VII). 
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40.  Preliminary  Design  Review  (PDR) 

40.1  General .  The  PDR  shall  be  a  formal  technical  review  of  the 
basic  design  approach  for  a  configuration  item  or  for  a 
functionally  related  group  of  configuration  items.  It  shall  be 
held  after  the  hardware  Development  Speci i  icat ion ( s ) ,  the  Software 
Top  Level  Design  Document  (STLDD),  the  Software  Tiast  Plan  (STP), 
the  HWCI  Test  Plan,  and  preliminary  versions  of  the  Computer 
System  Operator’s  Manual  (CSOM),  Software  User's  Manual  (SUM), 
Computer  System  Diagnostic  Manual  (CSDM),  and  Computer  Resources 
Integrated  Support  Document  (CRISD)  are  available,  but  prior  to 
the  start  of  detailed  design.  For  each  configuration  item  tne 
actions  described  below  may  be  accomplished  as  a  single  event,  or 
they  may  be  spread  over  several  events,  depending  on  the  nature 
and  the  extent  of  the  development  of  the  configuration  item,  and 
on  provisions  specified  in  the  contract  Stater  ant  of  Work.  A 
collective  PDR  for  a  group  of  configuration  items,  treating  each 
configuration  item  individually,  may  be  held  when  such  an  approach 
is  advantageous  to  the  contracting  agency;  such  a  collective  PDR 
may  also  be  spread  over  several  events,  as  for  a  single 
configuration  item.  The  overall  technical  program  risks 
associated  with  each  configuration  item  shall  also  be  reviewed  on 
a  technical,  cost,  and  schedule  basis.  For  software,  a  technical 
understanding  shall  be  reached  on  the  validity  and  the  degree  of 
completeness  of  the  STLDD,  STP,  and  the  preliminary  versions  of 
the  CSOM,  SUM,  CSDM.  and  CRISD. 

40.2  Items  to  be  Reviewed.  The  contractor  shall  present  the 

following  for  review  by  the  contracting  agency; 

40.2.1  tfWCIs: 

n.  Preliminary  design  synthesis  of  the  hardware  Development 
Specification  for  the  item  being  reviewed. 

b.  Trade-studies  and  design  studies  results  (see  paragraph 

20.3,2  of  SDR  for  s  representative  listing). 

c.  Functional  flow,  requirements  allocation  data,  and  schematic 
diagrams. 

d.  Equipment  layout  drawings  and  preliminary  drawings, 

including  any  proprietary  or  restricted 

design/process/components  and  information. 

e.  Environment  control  and  thermal  design  aspects 

f.  Electromagnetic  compatibility  of  the  preliminary  design 

g.  Power  distribution  and  grounding  design  aspects 

h.  Preliminary  mechanical  and  packaging  design  of  consoles, 
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racks,  drawers,  printed  circuit  boards,  connectors,  etc, 

i.  Safety  engineering  cons ideret ions 

j .  Security  engineering  considerations 

k.  Survivsbi lity/Vulnerability  (including  nuclear) 

considerations 

.  Preliminary  lists  of  materials,  parts,  and  processes 

m.  Pertinent  relability/maintainability/availability  data 

n.  Preliminary  weight  data 

o.  Development  test  data 


p.  Interface  requirements  contained  in  configuration  item 
Development  Specif i cations  and  interface  control  data  (e.g., 
interface  control  drawings)  derived  from  these  requirements 

q.  Configuration  item  development  schedule 

r.  Mock-ups,  models,  breadboards,  or  prototype  hardware  when 
appropriate 

s.  Producibility  and  Manufacturing  Considerations  (e.gflr 
materials,  tooling,  test  equipment,  processes,  facilities, 
skills,  and  inspection  techniques).  Identify  single  source, 
sole  source,  diminishing  source. 

t.  Value  Engineering  Considerations,  Preliminary  VECPs  and 
VECPs  (if  applicable). 

u.  Transportability,  packaging,  and  handling  considerations 

v.  Human  Engineering  and  Biomedical  considerations  (including 
life  support  and  Crew  Station  Requirements). 

w.  Standardization  considerations 


x.  Description  and  characterist ics  of  commercially  available 

equipment,  including  any  optional  capabilities  such  as 
special  features,  interface  units,  special  instructions, 
controls,  formats,  etc.,  (include  limitations  of 

commercially  available  equipment  such  as  failure  to  meet 
human  engineering,  safety,  and  maintainability  requirements 
of  the  specif ication  and  identify  deficiencies). 

y.  Existing  documentation  (technical  orders,  commercial 
manuals,  etc.,)  for  commercially  available  equipment  and 
copies  of  contractor  specifications  used  to  *  procu^jj 
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equipment  shall  be  made  available  for  review  by  the 
contracting  agency. 

z.  Firmware  to  be  provided  with  the  system:  microprogram  logic 
diagrams  and  reprogramming/instruction  translation  algorithm 
descriptions,  fabrication,  packaging  (integration  technology 
(e.g.,  LSI,  MSI),  device  types  (e.g.,  CMOS,  PMOS)),  and 
special  equipment  and  support  software  needed  for 
developing,  testing,  and  supporting  the  firmware. 

aa.  Life  Cycle  Cost  Analysis 

ab.  Armament  compatibility 

ac.  Corrosion  prevention/control  considerations 

ad.  Findings/Status  of  Quality  Assurance  Program 
40.2.2  CSCls: 

s.  Functional  flow.  The  computer  software  functional  flow 
embodying  all  of  the  requirements  allocated  from  the 
Software  Requirements  Specification  and  Interface 
Requirements  Speci f  j.cat ion( s )  to  the  individual  Top-Level 
Computer  Software  Components  (TLCSCs)  of  the  CSCI . 

b.  storage  allocation  data.  This  information  shall  be 

presented  for  each  CSCI  as  a  whole,  describing  the  manner  in 
which  available  storage  is  allocated  to  individual  TLCSCS. 
Timing,  sequencing  requirements,  and  relevant  equipment 
constraints  used  in  determining  the  allocation  are  to  be 
included. 

c.  Control  functions  description.  A  description  of  the 

executive  control  and  start/recovery  features  for  the  CSCI 
shall  be  available,  including  method  of  initiating  system 
operation  and  features  enabling  recovery  from  system 

malfunction. 

d.  CSCI  structure.  The  contractor  .shall  describe  the  top-level 

structure  of  the  CSCI,  the  reasons  for  choosing  the 

components  described,  the  development  methodology  which  will 
be  used  vithin  the  constraints  of  the  available  computer 
resources,  and  any  support  programs  which  will  be  required 
in  order  to  develop/maintain  the  CSCI  structure  and 
allocation  of  date  storage. 

e.  Security.  An  identification  of  unique  security  requirements 
and  a  description  of  the  techniques  to  be  used  for 
implementing  and  maintaining  security  within  the  CSCI  shall 
be  provided. 
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£ .  Reentrancy.  An  identification  of  any  reentranc 
requirements  and  a  description  of  the  techniques  for 
implementing  reentrant  routines  shall  be  available. 

g.  Computer  software  development  facilities.  The  availability, 
adequacy,  and  planned  utilisation  of  the  computer  softvare 
development  facilities  shall  be  addressed. 


h.  Computer  software  development  facility  versus  the 
operational  system.  The  contractor  shall  provide 
information  relative  to  unique  design  features  which  may 
exist  in  a  TLCSC  in  order  to  allow  use  within  the  computer 
software  development  facility,  but  which  will  not  exist  in 
the  TLCSC  installed  in  the  operational  system.  The 
contractor  shall  provide  information  on  the  design  of 
support  programs  not  explicitly  required  for  the  operational 
system  but  which  will  be  generated  to  assist  in  the 
development  of  the  CSCI(s).  The  contractor  shall  also 
provide  details  of  the  Softvare  Development  Library 
controls. 


i.  Development  tools.  The  contractor  shall  describe  any 
special  simulation,  data  reduction,  or  utility  tools  that 
are  not  deliverable  under  the  terms  of  the  contract,  but 
which  are  planned  for  use  during  softvare  development. 

j.  Test  tools.  The  contractor  shall  describe  any  special  test 
systems,  test  data,  data  reduction  tools,  test  computer 
softvare,  or  calibration  and  diagnostic  softvare  that  are 
not  deliverable  under  terms  of  the  contract,  but  which  are 
planned  for  use  during  product  development. 


k.  Description  and  characteristics  of  commercially  available 
computer  resources,  including  any  optional  capabilities  such 
as  special  features,  interface  units,  special  instructions, 
controls,  formats,  etc.  Include  Imitations  of  commercial ly 
available  equipment  suth  as  failure  to  meet  human 
engineering,  safety  and  maintainability  requirements  of  the 
specification  and  identify  deficiencies. 


1.  Existing  documentation  (technical  orders,  commercial 
manuals,  etc.)  for  commercially  available  computer  resources 
and  copies  of  contractor  specifications  used  to  procure 
computer  resources  shall  be  made  available  for  review  by  the 
contracting  agency. 


m.  Support  resources.  The  contractor  shall  describe  those 
resources  nycessary  to  support  the  software  and  firmware 
during  operational  deployment  of  the  system,  such  as 
operational  and  support  hardware  and  software,  personnel, 
special  skills,  human  factors,  configuration  management, 
test,  and  facilities/space. 
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и.  Operation  and  support  documents.  The  preliminary  versions 
of  the  CSOM,  SUM,  CSDm ,  and  CRISD  shall  be  revieved  for 
technical  content  .and  compatabil ity  with  the  top-level 
design  documentation. 

o.  Updates  since  the  last  review  to  all  previously  delivered 
software  related  CDRL  items. 

p.  Review  considerations  applicable  to  4C.2.1  as  appropriate. 

40.2.3  Support  Equipment  (SE) : 

a.  Review  considerations  Applicable  to  paragraph  40.2.1  and 
40.2.2  as  appropriate. 

b.  Verify  testability  analysis  results.  For  example,  on 

repairable  integrated  circuit  boards  are  test  points 

available  so  that  failures  can  be  isolated  to  the  lowest 
level  of  repair  (See  Section  3  Definitions,  for  "Levels  of 
repair* ) . 

c.  Verify  that  the  Government  furnished  SE  is  planned  to  be 
used  to  the  maximum  extent  possible. 

d.  Review  progress  of  long-lead  time  SE  items,  identified 
through  interim  release  and  SE  Requirements  Document  (SERD ) 
procedures . 

e.  Review  progress  toward  determining  total  SE  requirements  for 
installation,  checkout,  and  test  support  requirements. 

f.  Review  the  rel iabi 1 i ty/maintainabil i ty/availabi 1 i ty  of 
support  equipment  items. 

g.  Identify  ic fistic  support  requirements  for  support  equipment 
items  and  rationale  foi  their  selection. 

h.  Review  calibration  requirements. 

i.  Describe  technical  manuals  and  data  availability  for  support 
equipment. 

j.  Verify  compatibility  of  proposed  support  equipment  with  the 
system  maintenance  concept. 

к.  If  a  Logistic  Support  Analysis  (LSA)  is  not  done,  then 
review  the  results  of  SE  trade-off  studies  for  each 
alternative  support  concept.  For  existing  SE  and  printed 
circuit  board  testers,  review  Maintainability  data  resulting 
from  the  field  use  of  these  equipments.  Review  the  cost 
difference  between  systems  using  single  or  multipurpose  SE 
vs.  proposed  new  SE,  Examine  technical  feasibility  in 
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using  existing,  developmental,  and  proposed  nev  SE.  For 
mobile  systems,  review  the  mobility  requirements  of  support 
equipment. 

1.  Review  the  relationship  of  the  computer  resources  in  the 
system/subsystem  with  those  in  Automatic  Test  Equipment 
(ATE).  Relate  this  to  the  development  of  Built  In  Test 
Equipment  (BITE)  and  try  to  reduce  the  need  for  complex 
supporting  SE. 

40.3  Evaluation  of  Electrical ,  Mechanical ,  and  Logical  Des iqns 

40.3.1  HWCI s .  The  material  of  paragraph  40.2.1  above  shall  be 
evaluatec  to: 

a.  Determine  that  the  preliminary  detail  design  provides  the 
capability  of  satisfying  the  performance  characterist ics 
paragraph  of  the  HWCI  Development  specif icat ions . 

b.  Establish  compatibility  of  the  HWCI  operating 
character ist ics  in  each  mode  with  overall  system  design 
requirements  if  the  HWCI  is  involved  in  multi-mode 
functions. 


c.  Establish  the  existence  and  nature  of  physical  and 
functional  interfaces  between  the  HWCI  and  other  items  of 
equipment,  computer  software,  and  facilities. 


40.3.2  CSCIs.  The  material 
evaluated  to: 

of  paragraph  40.2. 

2 

above 

shall 

be 

a.  Determine  whether  all 

interfaces  between 

the 

CSC  I 

and 

all 

other  configuration  items  both  internal  and  external  to  the 
system  meet  the  requirements  of  the  Software  Requirements 
Specification  and  interface  Requirements  Specif icat ion <s> . 

b.  Determine  whether  the  top-level  design  embodies  all  the 
requirements  of  the  Software  Requirements  and  Interface 
Requirements  Specifications. 

c.  Determine  whether  the  approved  design  methodology  has  been 
used  for  tre  top-level  design. 

d.  Determine  whether  the  appropriate  Human  Factors  Engineering 
(HFE)  principals  have  been  incorporated  in  the  design. 

e.  Determine  whether  timing  and  sizing  constraints  have  been 
met  throughout  the  top-level  design. 

f.  Determine  whether  logic  affecting  system  and  nuclear  safety 
has  been  incorporated  in  the  design. 
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40.4  Electromagnetic  Compatibility.  Review  KWCI  design  for 
compl iance  with  electromagnetic  rompat ibi l i ty/electromagnetie 
interference  (EMC/EMI)  requirements.  Use  Electromagnet ic 
Compatibility  Plan  as  the  basis  for  this  review.  Check 
application  of  MU.-STDs  and  MIL-Specs  cited  by  the 
system/ equipment  specif ication(s)  to  the  HVC I /Subsystem  design. 
Review  preliminary  EMI  test  plans  to  assess  adequacy  to  confirm 
that  EMC  requirements  have  been  met. 

40.5  Design  Reliability. 

40.5.1  Identify  the  quantitative  reliability  requirements 
specified  in  the  hardware  Development  and  Software  Requirements 
Specif  ic.ation(s)  ,  including  design  allocations,  and  the  complexity 
of  the  CSCIs. 

40.5.2  Review  failure  rate  sources,  derating  polities,  and 
prediction  methods.  Review  the  reliability  mathematical  models 
and  block  diagrams  as  appropriate. 

40.5.3  Describe  planned  actions  when  predictions  are  less  than 
specified  requirements. 

40.5.4  Identify  and  review  parts  or  components  which  have  a 
critical  life  or  require  special  consideration,  and  general  plan 
for  handling.  Agencies  so  affected  shall  present  planned  actions 
to  deal  with  these  components  or  parts. 

40.  S. 5  Identify  applications  of  redundant  KWCI  elements.  Evaluate 
the  basis  for  their  use  and  provisions  fbr  “on-line"  switching  of 
the  redundant  elrm^nt. 

40.5.6  Review  critical  signal  paths  to  determine  that  a 
fail-safe/f ail-sott  design  has  been  provided. 

40.5.7  Review  margins  of  safety  for  HWCIs  between  functional 
requirements  and  design  provisions  for  elements,  such  as:  power 
supplies,  transmitter  modules,  motors,  and  hydraul-c  pumps. 
Similarly,  review  structural  -elements;  i.e.,  antenna  pedestals, 
dishes,  and  radooes  to  determine  that  adequate  margins  of  safety 
shall  ;be  provided  between  operational  stresses  and  design 
strengths . 

40.5.8  Review  Reliability  Design  Guidelines  for  HWCIs  to  insure 
that  design  reliability  concepts  shall  be  available  and  used  by 
equipment  designers.  Reliability  Design  Guidelines  shall  include, 
as  a  minimum,  part  application  guidelines  (electrical  derating, 
thermal  derating,  part  parameter  tolerances),  part  selection  order 
of  preference,  prohibited  parts/mater ials ,  reliability 
apport  iomr.ents/pr*dict  ions ,  and  management  procedures  to  ensure 
compliance  with  the  guidelines. 
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40.5.9  Review  for  HWCIs  preliminary  reliability  demonstration 
plan:  failure  counting  ground  rules,  accept- reject  criteria, 
number  of  test  articles,  test  location  and  environment,  planned 
starting  date,  and  test  duration. 

40.5.10  Review  elements  of  reliability  program  plan  to  determine 
that  each  task  has  been  initiated  toward  achieving  specified 
requirements. 


40.5.11  Review  subcontractor/supplier  reliability  controls. 

40.6  Design  Maintainability 

40.6.1  Identify  the  quantitative  maintainability  requirements 
specified  in  the  hardware  Development  and  Software  Requirements 
Specifications;  if  applicable,  compare  preliminary  predictions 
with  specified  requirements. 

40.6.2  Review  HWCI  preventive  maintenance  schedules  in  terms  of 
frequencies,  durations,  and  compatibility  with  system  schedules. 


40.6.3  Review  repair  rate  sources  and  prediction  methods. 

40.6.4  Review  planned  actions  when  predictions  indicate 
specified  requirements  will  not  be  attained. 


40.6.5  Review  planned  designs  for  accessibility ,  testability,  and 
ease  of  maintenance  characteristics  (including  provisions  for 
automatic  or  operator-controlled  recovery  from 
failure/malfunctions)  to  determine  consistency  with  specified 
requirements. 


40.6.6  Determine  if  planned  HWCI  design  indicates  that  parts, 
assemblies,  and  components  will  be  so  placed  that  there  is 
sufficient  space  to  use  test  probes,  soldering  irons,  and  other 
tools  without  difficulty  and  that  they  are  placed  so  that 
structural  members  of  units  do  not  prevent  access  to  them  or  their 
ease  of  removal. 


40.6.7  Review  provisions  for  diagnosing  cause(s)  of  failure;  means 
for  localizing  source  to  lowest  replaceable  element;  adequacy  and 
locations  of  planned  test  points;  and  planned  system  diagnostics 
that  provide  a  means  for  isolating  faults  to  and  within  the 
configuration  item  .  This  review  shall  encompass  on-line 
diagnostics,  off-line  diagnostics,  and  proposed  technical  orders 
and/or  commercial  manuals. 

40.6.8  Review  for  KWCIs  the  Design  for  Maintainability  Checklist 
to  insure  that  listed  design  principles  shall  lead  to  a  mature 
maintainability  design.  Determine  that  contractor  design 
engineers  are  using  the  checklist.  4 
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40.6.9  Evaluate  for  HWCls  the  preliminary  mair.tainebiii  y 
demonstration  plan,  including  numoer  of  maintenance  tasks  that 
shall  be  acccmpl ished;  accept-roject  criteria;  general  plans  for 
introducing  faults  into  tne  HWCI  and  personnel  involved  in  the 
demons t rat  ion. 

40.6.10  Review  elements  of  maintainability  program  plan  to 
determine  that  each  task  has  been  initiated  tovards  achieving 
specified  requi rements. 

40.6.11  Insure  that  consideration  has  been  given  to  optimizing  the 
syst«nv/i tern  from  •  maintainability  and  maintenance  viewpoint  and 
that  it  is  supportable  within  the  maintenance  concept  as 
developed.  Also,  for  HWCls  insure  that  a  Repair  Level  Analysis 
( RLA)  has  been  considered. 

40.7  Human  factors 

40.7.1  The  contractor  shall  present  evidence  that  substantiates 
the  functional  allocation  decisions.  The  Review  shall  cover  all 
operational  and  maintenance  functions  of  ;tie  configuration  item. 
In  particular,  ensure  that  the  approach  to  be  followed  emphasizes 
the  functional  integrity  of  the  man  with  the*  machine  to  accomplish 
a  system  operation. 

40.7.2  Review  design  data,  design  descript  i>np  end  drawings  on 
system  operations,  equipments,  and  facilities  to  insure  that  human 
performance  requirements  of  the  hardware  Development  and  Software 
Requirements  Specifications  are  met.  Exampie\  of  the  types  of 
design  information  to  be  reviewed  are: 

a.  Operating  modes  for  each  display  station,  and  £or  each  mode, 
the  functions  performed,  the  displays  und  control  used,  etc. 

b.  The  exact  format  and  content  of  each  display,  including  data 
locations,  spaces,  abbreviations,  the  number  of  digits,  all 
special  symbols  ( Pictographic ) ,  alert  mechanisms  (e.g., 
flashing  rates),  etc. 

c.  The  control  and  data  entry  devices  and  formats  including 
keyboards,  special  function  keys,  cursor  control,  etc. 

d.  The  format  of  all  operator  inputs,  together  with  provisions 
for  error  detection  and  correction. 

e.  All  status,  error,  and  data  printouts  -  including  formats, 
headings,  data  units,  abbreviations,  spacings,  columns,  etc. 

These  should  be  presented  in  sufficient  detail  to  allow 
contracting  agency  personnel  to  judge  adequacy  from  a  human 
usability  standpoint,-  and  design  personnel  to  know  whet  is 
required,  and  test  personnel  to  prepare  tests. 
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40.7.3  Make  i  ecoraaenc'it  ions  to  update  the  Syscem/Segment ,  or 
Software  Requirements  Specification  and  Interface  Requirements 
Specifications'  in  cases  where  requi  rumens  for  human  performance 
need  to  be  more  detailed. 

40.7.4  Review  man/machine  functions  to  insure  that  man’s 
capabilities  are  utilized  and  that  his  limitations  are  not 

exceeded. 

40.8  Svstem  Safety 

40.8.1  Review  results  of  configuration  item  safety  analyses,  and 
quantitative  hazard  analyses  (if  applicable). 

40.6.2  Review  results  of  system  and  int ra-system  safety  interfaces 
and  trade-off  studies  affecting  the  configuration  item. 


40.8,3  Review  safety  requirements  levied  on  subcontractors. 


40.8.4  Review  known  special  a.eas  of  safety,  peculiar  to  the 
nature  of  the  system  (e.g.,  fuel  handling,  fire  protection,  high 
levels  of  radiated  energy,  high  voltage  protection,  safety 
interlocks,  etc.). 


40.6.5  Review  results  of 
appropriate)  . 


prel iminary 


safety  tests 


40.8.6  Generally  review  adequacy  and  completeness  of  configuration 
item  from  dejign  safety  viewpoint. 


40.8.7  Review  compliance  of  commercially  available  configuration 
items  or  configuration  item  components  with  system  safety 
requirements  ana  identify  modifications  to  such  equipment,  if 
required. 

40.9  Natural  Environment 

40.9.1  Review  contractor’s  planned  design  approach  toward  meeting 
climatic  conditions  (operating  and  non-operating  ranges  for 
temperature,  humidity,  etc.)  that  are  specified  in  the  HWCI 
Development  Specif ication. 

40.9.2  insure  that  the  contractor  clearly  understands  the  effect 
of,  and  the  interactions  between,  the  natural  aerospace 
environment  and  HWCI  design.  in  cases  where  the  effect  and 
interactions  are  not  known  or  are  ambiguous,  insure  that  studies 
are  in  progress  or  planned  to  make  these  determinations. 


40.9.3  Current  and  forecast  natural  aerospace  environment 
parameters  may  be  needed  for  certain  configuration  items;  e.g., 
display  of  airbase  conditions  in  a  command  and  control  systgm.jflfck 
calculation  of  impact  point  for  a  missile,  etc.  Insure^aP 
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compatibility  between  the  configuration  item  design  and 
appropriate  meteorological  communications  by  comparing 
characteristics  of  the  source  (teletype,  facsimile,  or  data  link) 
with  that  of  the  configuration  item.  Insure  that  arrangements  or 
plans  to  obtain  needed  information  have  been  made  and  that 
adequate  display  of  natural  environmental  information  shall  be 
prov ided . 

40.10  Equipment  and  Part  Standardization 
40.10.1  Ecu i omen t  and  Components : 

a.  Review  current  and  planned  contractor  actions  to  determine 

that  equipment  or  components  for  which  standards  or 

specifications  exist  shall  be  used  whenever  practical. 
(Standard  item  with  NSN  should  have  first  preference). 

b.  Review  specific  trade-offs  or  modifications  that  may  be 
required  of  existing  designs  if  existing  items  are,  or  will 
be,  incorporated  in  the  HWCI. 

c.  Existing  designs  will  be  reviewed  for  use  or  non-use  based 
on  the  potential  impact  on  the  overall  program  in  the 
following  areas: 

(1)  Performance 

(2)  Cost 

(3)  Time 

(4)  Weight 

(5)  Size 

(6)  Reliability 

(7)  Maintainability 

(8)  Supportability 

(9)  Producibility 

d.  Review  HWCI  design  to  identify  areas  where  a  practical 
design  change  would  materially  increase  the  number  of 
standard  items  that  could  be  incorporated. 

e . 


Insure  that  Critical  Item  Specifications  shall  be  prepared 
for  hardware  items  identified  as  engineerxng  or  logistics 
critical . 
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40.10.2  Parts  Standardization  and  Interchangeability; 

a.  Review  procedures  to  determine  if  maximum  practical  use  will 
be  made  of  parts  built  to  approved  standards  or 
specifications.  The  potential  impact  on  the  overall  program 
is  to  be  evaluated  when  a  part  built  to  approved  standards 
and  spec i f icat ions  cannot  be  used  for  any  of  the  following 
reasons: 

(1)  Performance 

(2)  Weight 

( 3 )  Size 

( 4 )  Rel iabi 1 i ty/Manta inabi lity/ Availability 

(5)  Supportability 

(6)  Survivability  (including  nuclear) 

b.  Identify  potential  design  changes  that  will  permit  a  greater 
use  of  standard  or  preferred  parts  and  evaluate  the- 
trade-offs. 

c.  Insure  understanding  of  parts  control  program  operations  for 
selection  and  approval  of  parts  in  new  design  or  major 
modifications. 

d.  Reviev  status  of  the  Program  Parts  Selection  List. 

e.  Review  status  of  all  non-standard  parts  identified. 

f.  Review  pending  parts  control  actions  that  may  cause  program 
slippages,  such  as  non-availability  of  tested  parts. 

40.10.3  Assignment  of  Official  Nomenclature: 

a.  Insure  understanding  of  procedure  for  obtaining  assignment 
of  nomenclature  and  approval  of  nameplates. 

b.  Determine  that  a  nomenclature  conference  has  been  held  and 
agreement  has  been  reached  with  the  contracting  agency  on 
the  level  of  nomenclature;  i.e.,  system,  set,  central, 
group,  component,  sub-assembly,  unit,  etc. 

40.11  Value  Eng i neer inq 

40.11.1  Review  the  Contractor’s  in-house  incentive  Value 
Engineering  Program,  which  may  include  but  not  be  limited  to  the 
following; 


MIL-STD-15213 
APPEND I X  C 


a.  Contractor's  Value  Engineering  organizat ion,  policies  and 
procedures. 

b.  Contractor’s  Value  Engineering  Trai  ■ ' ng  Program. 

c.  Potential  Value  Engineering  projects,  studies  and  VECPs. 

d.  Schedule  of  planned  Value  Engineering  tasks/events . 

e.  Policies  and  procedures  for  subcontractor  Value  Engineering 
Programs. 

40.12  Transportability 

40.12.1  Review  HWC1  tc  determine  if  design  meets  contracts 
requirements  governing  size  and  weight  to  permit  economical 
handling,  loading,  securing,  transport ing ,  and  disassembly  for 
shipment  within  existing  capabilities  of  military  and  commercial 
carriers.  Identify  potential  outsized  and  overweight  items. 
Identify  system/i terns  defined  as  being  hazardous.  Ensure 
packaging  afforded  hazardous  items  complies  with  hazardous 
materials  regulations. 

40.12.2  Identify  HWCIs  requiring  special  temperature  and  humidity 
control  or  those  possessing  sensitive  and  shock  susceptibility 
characteristics.  Determine  special  transportation  requirements 
and  availability  for  use  with  these  HWCIs. 

40.12.3  Review  Transportability  Analysis  to  determine  that 
transportation  conditions  have  been  evaluated  and  that  these 
conditions  are  reflected  in  the  design  of  protective,  shipping, 
and  handling  devices.  In  addition  to  size  and  weight 
characteristics,  determine  that  analysis  includes  provisions  for 
temperature  and  humidity  controls,  minimization  of  sensitivity, 
susceptibility  to  shock,  and  transit  damage. 

40.13  Test 

40.13.1  Review  -all  changes  to  the  System/Segment,  HWCI 
Development,  Software  Requirements ,  and.  Interface  Requirements 
Specifications  subsequent  to  the  established  Allocated  Baseline  to 
determine  whether  Section  4.0  of  all  these  specifications 
adequately  reflects  these  changes. 

40.13.2  Review  information  to  be  provided  by  the  contractor 
regarding  test  concepts  for  Development  Test  and  Evaluation  (DTLE) 
testing  (both  informal  and  formal).  Information  shall  include: 

a.  The  organization  and  responsibilities  of  the  group  that  will 
be  responsible  for  test. 
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b.  The  management  of  his  in-house  development  test  effort 
provides  for: 


(1)  Test  Methods  (plans/procedures) 

(2)  Test  Reports 

(3)  Resolution  of  problems  and  errors 

(4)  Retest  procedure 

(5)  Change  control  and  configuration  management 

(6)  identification  of  any  special  test  tools  that 
are  not  deliverable  under  the  contract. 


c.  The  methodology  to  be  used  to  meet  quality  assurance 
requirements/qualification  requirements,  including  the  test 
repeatability  characteristics  end  approach  to  regression 
testing. 


d.  The  progress/status  of  the  test  effort  since  the  previous 
reporting  milestone. 

40.13.3  Review  status  of  all  negative  or  provisional  entries  sud^^ 
as  "not  applicable  <N/A)"  or  "to  b«  determined  ( TBD > "  in  SectioWr 
4.0  of  the  System/Segment,  hardware  Development,  Software 
Requirements  or  Interface  Requirements  Specifications,  Review  all 
positive  entries  for  technical  adequacy.  Insure  that  associated 
test  documentation  includes  these  changes. 


40.13.4  Review  interface  test  requirements  specified  in  Section 
4,0  of  the  hardware  Development,  Software  Requirements,  and 
Interface  Requirements  Specifications  for  compatibility,  currency, 
technical  adequacy,  elimination  of  redundant  test.  Insure  that 
all  associated  test  documents  reflect  these  interface 
requirements. 


40.13.5  Insure  that  all  test  planning  documentation  has  been 
updated  to  include  new  test  support  requirements  and  provisions 
for  Long-lead  time  support  requirements. 

40.13.6  Review  contractor  test  data  from  prior  testing  to 
determine  if  such  data  negates  the  need  for  additional  testing. 

40.13.7  Examine  all  available  breadboards,  mock-ups,  or  devices 
which  will  be  used  in  implementing  the  test  program  or  which 
affect  the  test  program,  for  program  impact. 

40.13.8  Review  plans  for  software  Unit  testing  to  ensure  that 

tney : 

W 
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a.  Address  Unit  level  si2i«ng,  timing,  and  accuracy 
requirements. 

b„  Present  general  and  specific  requirements  that  will  be 
demonstrated  by  Unit  testing. 

c.  Describe  the  required  test-unique  support  software, 
hardware,  and  facilities  and  the  interrelationship  of  these 
items. 

d.  Describe  how,  when,  and  from  where  the  test-unique  support 
items  will  be  obtained. 

e.  Provide  test  schedules  consistent  with  higher  level  plans. 

40.13.9  Review  plans  for  CSC  integration  testing  to  ensure  that 
they: 

a.  Define  the  type  of  testing  required  for  each  level  of  the 
software  structure  above  the  unit  level. 

b.  Present  general  and  specific  requirements  that  will  be 
demonstrated  by  CSC  integration  testing.1 

e.  Describe  the  required  test-unique  support  software, 
hardware,  and  facilities .  and  r.he  interrelationship  of  these  ' 
items. 

d.  Describe  how,  when,  and  from  where  the  test-unique  support 
items  will  be  obtained. 

e.  Describe  CSC  integration  test  management,  to  include: 

<1)  Organisation  and  responsibilities  of  the  test  team 

(2)  Control  procedures  to  be  applied  during  test 

(3)  Test  reporting 

(4)  Review  of  CSC  integration  test  results 

(5)  Generation  of  data  to  be  used  in  CSC 
integration  testing. 

f.  Provide  test  schedules  consistent  with  higher  level  plans. 

40.13.10  Review  plans  for  formal  CSC1  testing  to  ensure  that  they: 

a.  Define  the  objective  of  each  CSCI  test,  and  relate  the  test 
to  the  software  requirements  being  tested. 
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b.  Relate  formal  CSCI  tests  to  other  test  phases. 

c.  Describe  support  software,  hardware,  and  facilities  required 
for  CSCI  testing;  and  how,  when,  ar.d  from  where  they  will  be 
obtained. 

d.  Describe  CSCI  test  roles  and  responsibilities. 

e.  Describe  requirements  for  Government-provided  software, 
hardware,  facilities,  data,  and  documentation. 

f.  Provide  CSCI  test  schedules  consistent  with  higher-level 
plans . 

g.  Identify  software  requirements  that  will  be  verified  by  each 
formal  CSCI  test. 

40.14  Maintenance  and  Maintenance  Data  ( Kwcis  > 

40.14.1  Describe  System  Maintenance  concept  for  impact  on  design 
and  SE.  Review  adequacy  of  maintenance  plans.  Coverage  shall  be 
provided  for  On  Equipment  (Organizational),  Off  Equipment  -  On 
Site  ( Intermediate) ,  Off  Equipment  -  Off  Site 
maintenance  of  Government  Furnished  Equipment 
Contractor  Furnished  Equipment  ( CFE ) .  (See 

Definitions,  para  3,12  for  levels  of  maintenance.) 

« 


(Depot)  level 
(GFE) ,  and 
Section  3, 


40.14.2  Determine  degree  of  understanding  of  the  backgroun_. 
purpose,  requirements,  and  usage;  of  Maintenance  (failure)  Data 
Collection  and  Historical/Status  Records.  (Ref  Data  Item  titled, 
"Reliability  and  Maintainability  Data  Reporting  and  Feedback 
Failure  Summary  Report's"). 

40.14.3  Describe  method  of  providing  Maintenance,  Failure, 
Reliability.  Maintainability  Data  to  contracting  agency. 


40.14.4  Desc 
agency  for 
Order  Number 


::be  how  requirements  are 
Equipment  Classification 
Pref ix/Suf f i x  Codes)  when 


submitted  to  the  contracting 
lEQ/CL)  Codes  (formerly  Work 
this  requirement  exists. 


Coding  of  the 
for  documen  t  i  r.g 
i tem/Subsystem 
Orders"  and  the 


40.14.5  Review  plans  for  (and  status  of)  work  Unit 
equipment.  work  Unit  codes  shall  be  available 
Maintenance  Data  commencing  with  configuration 
Testing.  (Ref.  Data  Item  titled  "Technical 
military  specification  on  work  unit  coding). 

40.15  Spares  and  Government  Furn i shed  Property  ( GFP )  . 

40.15.1  Review  logistics  ar.d  provisioning  planning  to  insure  full 
understanding  of  scope  of  requirements  in  these  areas  and  that  a 
reasonable  time-phased  plan  has  been  developed  for  accomplishment. 
Of  specific  concern  are  the  areas  of:  provisioning  requirement^ 


MIL-STD-J521B 
APPENDIX  D 


GFP  usage,  and  spare  parts,  and  support  during  installation, 
checkout,  and  test. 

40.15.2  Review  provisioning  actions  and  identify  existing  or 
potential  provisioning  problems  -  logistic  critical  and  long-lead 
time  items  are  identified  and  evaluated  against  use  of  the  interim 
release  requirements . 

40.15.3  Review  plans  for  maximum  screening  and  usage  of  GFP,  and 
extent  plans  have  been  implemented. 

40.15.4  Review  progress  toward  determining  and  acquiring  total 
installat ion,  checkout,  and  test  support  requirements. 

40.16  Packag ina/SPP£  (Special  Design  Protective  Ecu i omen t ) 

40.16.1  Analyze  all  available  specifications  (System/Segment,  HWCI 
Development,  Software  Requirements,  Interface  Requirements,  and 
Critical  Items)  for  packaging  (Section  5)  requirements  for  each 
product  fabrication  and  material  specification. 

40.16.2  Evaluate  user/operational  support  requirements  and 
maintenance  concepts  for  effect  and  influence  on  package  design. 

40.16.3  Establish  that  time  phased  plan  for  package  design 
development  is  in  consonance  with  the  development  of  the  equipment 
design. 

40.16.4  Review  planned  and/or  preliminary  equipment  designs  for 
ease  of  packaging  and  simplicity  of  package  design,  and  identify 
areas  where  a  practical  design  change  would  materially  decrease 
cost,  weight,  or  volume  of  packaging  required. 

40.16.5  Review  requirements  for  SDPS  necessary  to  effectively 
support  configuration  item  during  transportat ion ,  handling  and 
storage  processes.  Insure  SDPE  is  categorized  as  a  configuration 
item  utilizing  specifications  conforming  to  the  types  and  forms  as 
prescribed  in  the  contract.  Review  SDPE  development/product 
specif ications  for  adequacy  of  performance/interface  requirements. 

40.1-6.6  Determine  initial  package  design  baselines,  concepts, 
parameters,  constraints,  -etc. ,  to  the  extent  possible  at  this 
phase  of  the  configuration  item  development  process. 

40.16.7  Insure  previously  developed  and  approved  package  design 
data  for  like  or  similar  configuration  items  is  being  utilized. 

40.16.8  Establish  plans  for  trade  studies  to  determine  the  most 
economical  and  desirable  packaging  design  approach  needed  to 
satisfy  the  functional  performance  and  logistic  requirements. 
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46.16.9  Verify  the  adequacy  of 


the  prototype  package  design. 


40.16.10  Review  Section  5  of  Specification  to  insure  full 
understanding  by  contractor  for  contractor  requirements.  Identify 
package  specif ication  used  for  hazardous  materials. 


40.17  Technical  Manuals 


40.17.1  Review  status  of  the  "Technical  Manual  Publications  Plan" 
to  insure  that  all  aspects  of  the  plan  have  been  considered  to  the 
extent  that  all  concerned  agencies  are  apprised  of  the  technical 
manual  coverage  to  be  obtained  under  this  procurement.  The 
suitability  of  available  commercial  manuals  and/or  modifications 
thereto  shall  also  be  determined. 


4D.17.2  Review  the  availability  of  technical  manuals  for 
validation/verification  during  the  latter  phases  of  DT&E  testing. 


40.17.3  If  a  Guidance  Conference  was  not  accomplished  or  if  open 
items  resulted  from  it,  then  review  as  applicable  provisions  for 
accomplishing  TO  in-process  reviews,  validation,  verification, 
prepublication,  and  postpublication  reviews. 

40.18  System  Allocation  Document 


40.18.1  Review  the  Draft  System  Allocation  Document 
completeness  and  technical  adequacy  to  extent  completed. 


40.13.2  The  format  shall  provide  the  following  minimum 
information: 


a.  Drawing  Number 

b.  Issue 

c.  Number  of  Sheets 

d.  Location 

e.  Configuration  Item  Number 

f.  Title 

g.  Part  Number 

h.  Serial  Number 

i.  Specification  Number 

j.  Equipment  Nomenclature 

k.  Configuration  Item  Quantity 

l.  Assembly  Drawing 


40.19  Des inn  Producibi 1 i ty  and  Manufacturing 


,j.  1  -it.  contractor  shal 
manufacturing  engineering 
process . 


1  demonstrate  and  present  evidence  that 
will  be  integrated  into  the  design 
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a.  The  contractor  shall  provide  evidence  of  performing 
produc ibi 1 ity  analyses  on  development  hardware  trading  off 
design  requirements  against  manufacturing  risk,  cost, 
production,  volume,  and  existing  capabi 1 i ty/avai lab; 1 i ty . 

Evidence  of  such  analyses  may  be  in  the  contractor's  own 
format  but  must  conclusively  demonstrate  that  in-depth 
analyses  were  performed  by  qualified 

organizations/ir.dividuais  and  the  results  of  those  analyses 
will  be  incorporated  in  the  design. 

b.  Preliminary  manufacturing  engineering  and  production 

planning  demonstrations  shall  address:  material  and 

component  selection,  preliminary  production  sequencing, 
methods  and  flow  concepts,  new  processes,  manufacturing 
risk,  equipment  and  facility  utilization  for  intended  rates 
and  volume,  production  in-process  and  acceptance  test  and 
inspection  concepts.  (Efforts  tD  maximize  productivity  in 
the  above  areas  should  be  demonstrated. ) 

c.  Management  systems  to  be  utilized  will  insure  that 

produc ibi 1 ity  and,  manufacturing  cons iderat ions  are 
integrated  throughout  the  FSD  effort. 

40.19.2  The  produc ibi i i ty  and  manufacturing  concerns  identified  in 
the  SRR  and  the  SDR  shall  be  updated  and  expanded  to: 

a.  Provide  evidence  that  concerns  identified  in  the 

Manufacturing  Feasibility  Assessment  and  the  Production 
Capability  Estimate  have  been  addressed  and  that  resolutions 
are  planned  or  have  been  performed. 

b,  Make  recommendations  including  manufacturing  technology 
efforts  and  provide  a  schedule  of  necessary  actions  to  the 
program  office  to  resolve  open  manufacturing  concerns  and 
reduce  manufacturing  risk. 

40.20  Post  Review  Action 

40.20.1  After  completing  the  PDR ,  the  contractor  shall  publish  and 
distribute  copies  of  Review  minutes.  The  contracting  agency 
officially  acknowledges  completion  of  a  PDR  as  indicated  in 
paragraph  4.2.4. 

40.20.2  The  accomplishment  of  the  PDR  shall  be  recorded  on  the 
configuration  item  Development  Record  by  the  contractor. 
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50.  Critical  Design  Review 

50.1  Genera  1 .  The  CDR  shall  be  conducted  on  each  configuration 
item  prior  to  fabrication/producticn/coding  release  to  insure  that 
the  detail  design  solutions,  as  reflected  in  the  Draft  Hardware 
Product  Specification,  Software  Detailed  Design  Document  ( SDDD) , 
Data  Base  Design  Document(s)  { DBDD ( s ) ) ,  Interface  Design 
Document (s)  (IDD(s)),  and  engineering  drawings  satisfy 
requirements  established  by  the  hardware  Development  Specification 
and  Software  Top  Level  Design  Document  (STLDD).  CDR  shall  be  held 
after  the  Computer  Software  Operator's  Manual  (CSOM),  Software 
User's  Manual  (SUM),  Computer  System  Diagnostic  Manual  (CSDM), 
Software  Programmer's  Manual  (SPM),  and  Firmware  Support  Manual 
(FSM)  have  been  updated  or  newly  released.  For  complex/large 
configuration  items  the  CDR  may  be  conducted  on  an  incremental 
basis .  i.e.,  progressive  reviews  are  conducted  versus  a  single 
CDR.  The  overall  technical  program  risks  associated  with  each 
configuration  item  shall  also  be  reviewed  on  a  technical  (design 
and  manufacturing),  cost  and  schedule  basis.  for  software,  a 
technical  understanding  shall  be  reached  on  the  validity  and  the 
degree  of  completeness  of  the  SDDD,  IDD(s),  DBDD(s),  STD,  CKISD, 
SPM,  and  FSM,  and  preliminary  versions  of  the  CSOM,  SUM,  and  C5DM. 

50.1.1  equipmcnt/raci 1 it ies  conf igurat ion  items.  The  detail 
design  as  disclosed  By  the  "'Hardware  Product-  Specification, 
drawings,  schematics,  mockups,  etc.,  shall.be  reviewed  against  the 
HVCI  Development  Specification  performance  requirements.  For 
other  than  facilities,  the  result  of  a  successful  CDR  shall  be  the 
establishment  of  the  design  baseline  tor  detailed 
fabrication/production  planning  i.e.,  the  contractor  is  permitted 
to  use  the  detail  design  as  presented  at  CDR  and  reflected  in  the 
hardware  Product  specification  for  planning  for  production  and,  if 
specifically  authorized,  for  initial  fabrication/production 
efforts. 

50.1.2  Computer  Software  conf igurat ion  items  ( CSC Is).  The  CDR  for 
a  CSCI  shaTT~  Ee  a  Formal  technicaT  review  of  the  CSCI  detail 
design,  including  data  base  and  interfaces.  The  CDR  is  normally 
accomplished  for  the  purpose  of  establishing  integrity  of  computer 
software  design  at  the  level  of  a  Unit's  logical  design  .prior  to 
coding  and  tasting.  CDR  may  be  accomplished  at  a  single  review 
meeting  or  in  increments  during  the  development  process 
corresponding  to  periods  at  which  components  or  groups  of 
components  reach  the  completion  of  logical  design.  The  primary 
product  of  the  CDR  is  e  formal  identification  of  specific  software 
documentat ion  which  will  be  released  for  coding  and  testing.  By 
mutual  agreement  between  the  contractor  and  the  contracting 
agency,  COR a  may  be  scheduled  concurrently  for  two  or  more  CSCIs. 

50.1.2.1  Since  computer  software  development  is  an  iterative 
process,  the  completion  of  a  CDR  for  a  CSCI  is  not  necessarily 
sufficient  for  maintaining  adequate  visibility  into  the  remaining 
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development  effort  through  testing. 

50.1.2.2  Additional  In-Prcgress  Reviews  may  be  scheduled  post-CDR 
which  address: 

a.  Response  to  outstanding  action  items 

b.  Modifications  to  design  necessitated  by  approved  ECPs  or 
design/prog ram  errors 

c.  Updating  sizing  and  timing  data 

d.  Updated  design  information,  as  applicable 

e.  Results  obtained  during  in-house  testing,  including  problems 
encountered  and  solutions  implemented  or  proposed, 

50.2  Items  to  be  Rev i ewed .  The  contractor  shall  present  the 
following  for  review  by  the’  contracting  agency: 

50.2.1  HWCIs 

a.  Adequacy  of  the  detail  design  reflected  in  the  draft 
hardware  Product  Specification  in  satisfying  the 
requirements  of  the  Hwci  Development  Specification  for  the 
item  being  reviewed. 

b.  Detail  engineering  drawings  for  the  HWCI  including  schematic 
diagrams. 

c.  Adequacy  of  the  detailed  design  in  the  following  areas: 

(1)  Electrical  design 

(2)  Mechanical  design 

(3)  Environmental  control  and  thermal  aspects 

(4)  Electromagnetic  compatibility 

(5)  Power  generation  and  grounding 

(5)  Electrical  and  mechanical  interface  compatibility 

(7)  Mass  properties 

( 8 )  Reliabi 1 ity/Maintainabi 1: ty/Availabi 1 ity 

(9)  System  Safety  Engineering 

(10)  Security  Engineering 
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(11)  Survivabiiity/Vulnerabil ity  (including  nuclear) 

(12)  Produc ibi 1 i ty  and  Manufacturing 

(13)  Transportability,  Packaging  and  handling 

(14)  Human  Engineering  and  Biomedical  Requirements  (including 
Life  Support  and  Crew  Station  Requirements) 

(15)  Standardizat ion 

(16)  Design  versus  Logistics  Trade-offs 

d.  Interface  control  drawings 

e.  Mock-ups,  breadboards,  and/or  prototype  hardware 

f.  Design  analysis  and  test  data 

g.  System  Allocation  Document  for  KWCI  inclusion  at  each 
scheduled  location, 

h.  Initial  Manufacturing  Readiness  (for  example,  manufacturing 

engineering,  tooling  demonstrat ions ,  development  and 

proofing  of  new  materials,  processes,  methods,  tooling,  test 
equipment,  procedures,  reduction  of  manufacturing  risks  to 
acceptable  levels). 

i.  Preliminary  VECFs  and/or  formal  VECPs 

j.  Life  cycle  costs 

k.  Detail  design  information  on  all  firmware  to  be  provided 
with  the  system, 

l.  Verify  corrosion  prevention/control  considerations  to  insure 
materials  have  been  chosen  that  will  be  compatible  with 
operating  environment. 

m.  Findings/Status  of  Quality  Assurance  Program 
SO. 2. 2  CSCIs . 

a.  Software  Detailed  Design,  Data  Base  Design,  and  Interface 
Design  Document  ( s )  .  in  cases  where  the  C.DR  is  conducted  in 
increments,  complete  documents  to  support  that  increment 
shall  be  available. 

b.  Supporting  documentation  describing  results  of  analyses, 
testing,  etc.,  as  mutually  agreed  by  the  contracting  agency 
and  the  contractor. 
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System  Allocation  Document  for  CSCI  inclusion  at  each 
scheduled  location. 


Computer  Resources  Integrated  Support  Document. 

Software  Programmer's  Manual 
Firmware  Support  Manual 

Progress  on  activities  required  by  CSCI  PDR  (para  40.2.2), 
Updated  operation  and  support  documents  (CSOM,  sum,  CSDM) . 
Schedules  for  remaining  milestones. 

Updates  since  the  last  review  to  all  previously  delivered 
software  related  CURL  items. 


50.2.3  Support  Equipment  (SE): 


a.  Review  requirements  (paragraphs  50.2.1  and  50.2.2)  .for  SE. 

b.  Verify  maximum  considerations  GFE  SE  4 

c.  Identify  existing  or  potential  SE  provisioning  problems 

d.  Determine  qualitative  and  quantitative  adequacy  of 
provisioning  drawings  and  data 

e.  Review  reliability  of  SE 

f.  Review  logistic  support  requirements  for  SE  items 

g.  Review  calibration  requirements 

h.  Review  documentation  for  SE. 

50-3  Detailed  Evaluation  of  Electrical ,  Mechanical .  and  Logical 
Designs  ♦  ~  '  ™  ” 

50.3.1  HWCIs.  Detailed  block  diagrams,  schematics,  and  logic 
diagrams  shall  be  compared  with  interface  control  drawings  to 
determine  system  compatibility.  Analytical  and  available  test 
data  shall  be  reviewed  to  insure  the  hardware  Development 
Specification  has  been  satisfied. 

50.3.1.1  The  contractor  shall  provide  information  on  firmware 
which  is  included  in  commercially  available  equipment  or  to  be 
included  in  equipment  developed  under  the  contract.  Firmware  in 
this  context  includes  the  microprocessor  and  associated  sequence^ 
of  micro- instructions  necessary  to  perform  the  allocated  tasks.® 
As  a  minimum,  the  information  presented  during  CDR  shall  provide 
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descriptions  and  status  for  the  following: 

a.  Detailed  logic  flow  diagrams 

b.  Processing  algorithms 

c.  Circuit  diagrams 

d.  Clock  and  timing  data  (e.g.,  timing  charts  for 
micro-instructions ) 

e.  Memory  (e.g.,  type  {RAM,  PROM),  word  length,  size  (total  and 
spare  capacity)) 

f.  Micro-instruction  list  and  format 

g.  Device  functional  instruction  set  obtained  by  implementation 
of  firmware. 

h.  Input/output  data  width  (i.e.,  number  of  bits  for  data  and 
control. ) 

i.  Self-test  (diagnost ics)  within  firmware. 

j.  Support  software  for  firmware  development: 

(1)  Resident  assembler 

(2)  Loader 

(3)  Debugging  routines 

(4)  Executive  (monitor) 

(5)  Non-resident  diagnostics 

(6)  Cross  assemble:  and  higher  level  language  on  host 
computer 

(7)  instruction  ^simulator 

50. 3.2  CSCIs .  The  contractor  shall  present  the  detailed  design 
(including  rationale)  of  the  CSCI  to  include: 

a.  The  assignment  of  CSCI  requirements  to  specific  Lower-Level 
Computer  Software  Components  (LLCSCs)  and  Units,  the 

criteria  and  design  rules  used  to  accomplish  this 
assignment,  and  the  traceability  of  Unit  and  LLCSC  designs 
to  satisfy  CSCI  requirements,  with  emphasis  on  the  necessity 
and  sufficiency  cf  the  Units  for  implementing  TLCSC  design 
requirements 
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b.  The  overall  information  flow  between  software  Units,  the 
method(s)  by  which  each  Unit  gains  control,  and  the 
sequencing  of  Units  relative  to  each  other. 

c.  The  design  details  of  the  CSC I,  TLCSCs,  LLCSCs,  and  Units 
including  data  definitions,  timing  and  sizing,  data  and 
storage  requirements  and  allocations. 

d.  The  detailed  design  characteristics  of  all  interfaces, 
including  their  data  source,  destination,  interface  name  and 
interrelationships;  and,  if  applicable,  the  design  for 
direct  memory  access.  The  contractor  shall  also  give  an 
overview  of  the  key  design  issues  of  the  interface  software 
design,  and  indicate  whether  data  flow  formats  are  fixed  or 
subject  to  extensive  dynamic  changes. 

e.  The  detailed  characteristics  of  the  data  base.  Data  base 
structure  and  detailed  design,  including  all  files,  records, 
fields,  and  items.  Access  rules,  how  file  sharing  will  be 
controlled,  procedures  for  data  base  recovery/regeneration 
from  a  system  failure,  rules  for  data  base  manipulation, 
rules  for  maintaining  file  integrity,  rules  for  usage 
reporting,  and  rules  governing  the  types  and  depth  of  access 
shall  be  defined.  Data  management  rules  and  algorithms  for 
implementing  them  shall  be  described.  Details  of  th^ 
language  required  by  the  user  to  access  the  data  base  shall^ 
also  be  described. 


50 . 4  Electromagnet i c  Comoat ibi 1 ity: 

a.  Review  contractor  EMC  design  of  all  HWCls.  Determine 
compliance  with  requirements  of  the  Electromagnetic 
Compatibility  Plan  and  HWCI  specifications. 

b.  Review  system  EMC  including  effects  on  the  electromagnetic 
environment  (inter-system  EMC)  and  ir.tra-system  EMC. 
Determine  acceptability  of  EMC  design  and  progress  toward 
meeting  contractual  EMC  requirements. 

c.  Review  EMC  test  plans.  Determine  adequacy  to  confirm  EMC 
design  characteristics  of  the  system/KWCl /subsystem. 

50.5  Design  Rel iabi 1 itv: 

50.5.1  Review  the  most  recent  predictions  of  hardware  and  software 
reliability  and  compare  against  requirements  specified  in  hardware 
Development  Specification  and  Software  Requirements  Specification. 

For  hardware,  predictions  are  substantiated  by  review  of  parts 
application  stress  data. 

50.5.2  Review  applications  of  parts  or  conf  igurat  ion  items  wit)^^ 
minimum  life,  or  those  which  require  special  consideration  td^p 
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insure  their  effect  on  system  performance  is  minimized. 

50.5.3  Review  completed  Reliability  Design  Review  Checklist  to 
insure  principles  have  been  satisfactorily  reflected  in  the 
configuration  item  design. 

50.5.4  Review  applications  of  redundant  configuration  item 
elements  or  components  to  establish  that  expectations  have 
materialized  since  the  PDR. 

50.5.5  Review  detailed  HWCI  reliability  demonstration  plan  for 
compatibility  with  specified  test  requirements.  The  number  of 
test  articles,  schedules,  locations,  test  conditions.  and 
personnel  involved  are  reviewed  to  insure  a  mutual  understanding 
of  the  plan  and  to  provide  overall  planning  information  to 
activities  concerned. 

50.5.6  Review  the  failure  data  reporting  procedures  and  methods 
for  determination  of  failure  trends. 

50.5.7  Review  the  thermal  analysis  of  components,  printed  circuit 
cards,  modules,  etc.  Determine  if  these  data  are  used  in' 
performing  the  detailed  reliability  stress  predictions. 

50 .5.8  Review  on-line  diagnostic  programs,  off-line  diagnostic 
programs ,  support  equipment,  and  preliminary  technical  orders 
( and/or  commercial  manuals)  for  compliance  with  the  system 
maintenance  concept  and  specification  requirements. 

50.5.9  Review  software  reliability  prediction  model  and  its 
updates  based  upon  test  data  and  refined  predictions  of  component 
usage  rates  and  complexity  factors. 

50.6  Design  Maintainabil ity 

50.6.1  Review  the  most  recent  predictions  of  quantitative 
maintainability  and  compare  these  against  requirements  specified 
in  the  HWCI  Development  Specification  and  Software  Requirements 
Specification. 

50.6.2  Review  prevent ive  ma intenance  frequencies  and  durations  for 
compatibility  with  overall  system  requirements  and  planning 
criteria. 

50.6.3  Identify  unique  maintenance  procedures  required  for  the 
configuration  item  during  operational  use  and  evaluate  their  total 
effects  on  system  maintenance  concepts.  Assure  that  system  is 
optimized  from  a  maintenance  and  ma intainaoi 1 ity  viewpoint  and 
conforms  with  the  planned  maintenance  concept.  This  shall  include 
a  review  of  provisions  for  automatic,  semi-automatic,  and  manual 
recovery  from  hardware/sof tware  failures  and  malfunctions. 
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50.6.4  Identify  design-for-maintainability  criteria  provided  by 
the  checklist  in  the  design  detail  to  insure  that  criteria  have, 
in  fact  been  incorporated. 

50.6.5  Determine  if  parts,  assemblies,  and  other  items  are  so 
placed  that  there  is  sufficient  space  to  use  test  probes, 
soldering  irons,  and  other  tools  without  difficulty  and  that  they 
are  placed  so  that  structural  members  of  units  do  not  prevent 
access  to  them  or  their  ease  of  removal. 

50.6.6  Review  detailed  maintainability  demonstration  plan  for 
compatibility  with  specified  test  requirements.  Supplemental 
information  is  provided  and  reviewed  to  insure  a  mutual 
understanding  of  the  plan  and  to  provide  overall  planning 
information  to  activities  concerned. 


50.7  Human  Factors 


50.7.1  Review  detail  design  presented  on  drawings,  schematics, 
mockup3,  or  actual  hardware  to  determine  that  it  meets  human 
performance  requirements  of  the  HVCI  Development  Specification  and 
Software  Requirements  Specification,  Interface  Requirements 
Specification^),  and  accepted  human  engineering  practices. 


50,7.2  Demonstrate  by  checklist  or  other  formal  means  the 
of  design  for  human  performance. 


adequ 


50.7.3  Review  each  facet  of  design  for  man/machine  compatibility. 
Review  time/cost/effectiveness  considerations  and  forced 
trade-offs  of  human  engineering  design. 


50.7.4  Evaluate  the  following  human  engineering/biomedical  design 
factors : 


a.  Operator  controls 

b.  Operator  displays 

c.  Maintenance  features 

d.  Anthropometry 

e.  Safety  features  and  emergency  equipment 

f.  Work  space  layout 

g.  Internal  environmental  conditions  (noise, 
vent i let  ion,  etc, ) 

h.  Training  equipment 

i.  Personnel  accommodations 


lighting. 
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SO. 8  System  Safety 

50.8.1  Review  configuration  item  detail  design  for  compliance  to 
safety  design  requirements. 

50.8.2  Review  acceptance  test  requirements  to  insure  adequate 
safety  requirements  are  reflected  therein. 

50.8.3  Evaluate  adequacy  of  detailed  design  for  safety  and 
protective  equipment /dev ices . 

50.8.4  Review  configuration  item  operational  maintenance  safety 
analyses  and  procedures. 

50.5  Natural  Environment 

50.9.1  Review  detail  design  to  determine  that  it  meets  natural 


environment 
Specif ication. 

requirements 

of 

the 

hardware 

Development 

50.9.2  Insure 

thct  studies 

have 

been 

accompl ished 

concerning 

effects  of  the  natural  environment  on,  or  interactions  with,  the 
HWCI .  Studies  which  have  been  in  progress  shall  be  complete  at 
this  time. 

50.9.3  Determine  vhether  arrangements  have  been  .  made  to  obtain 
current  and/or  forecast  natural  environment  information,  when 
needed  for  certain  HWCIs.  Assure  compatibility  of  HWCI  and  source 
of  information  by  comparing  electrical  character ist i cs  and  formats 
for  the  source  and  the  HWCI. 

5C.10  Equipment  and  Parts  Standardizat ion . 

50.10.1  Equipment  and  Components .  Determine  that  every  reasonable 
action  has  been  taken  to  fulfill  the  standardization  requirements 
for  use  of  standard  items  (standard  item  with  N5N  should  be  first 
preference)  and  to  obtain  approval  for  use  of  non-standard  or 
non-preferred  items.  Accordingly,  the  following  criteria  shall  be 
evaluated: 

a.  Data  sources  that  were  reviewed. 

b.  Factors  that  were  considered  in  the  decision  to  reject  known 
similar,  existing  designs. 

c.  Factors  that  were  considered  in  decisions  to  accept  any 
existing  designs  which  were  incorporated,  and  the 
trade-offs,  if  any,  that  had  to  be  made. 


50.10.2  Parts 

a.  Determine  whether  there  are  any  outstanding  non-standard  or 
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non-preferred  parts  approval  requests  and  action  necessary 
for  approval  or  disapproval.  (Status  of  parts  control 
program  operations). 


b.  Identify  non-standard-non-pref erred  parts  approval  problems 
and  statvis  of  actions  toward  resolving  the  problems. 

c.  Review  potential  fabrication/product  ion  line  delays  due  to 
non-availability  of  standard  or  preferred  parts.  In  such 
cases,  determine  whether  it  is  planned  to  request  use  of 
parts  which  may  be  replaced  by  standard  items  during 
subsequent  support  repair  cycles.  Assure  that  appropriate  . 
documentation  makes  note  of  these  items  and  that  standard 
replacement  items  shall  be  provisioned  for  support  and  used 
for  repair. 


d.  Require  certi f icat ion  that  maximum  practical 

interchangeability  of  parts  exists  among  components, 
assemblies,  and  HWCIs.  Reservations  concerning 

interchangeability  are  identified,  particularly  for  hardness 
critical  items. 


e.  Sample  preliminary  drawings  and  cross  check  to  insure  that 
parts  indicated  on  the  drawings  are  compatible  with  the 
Program  Parts  Selection  List. 

50.10.3  Assignment  of  Official  Nomenclature. 

a.  Determine  whether  official  nomenclature  and  approval  of 
nameplates  have  been  obtained  to  extent  practical. 

b.  Determine  whether  DD  Form  61,  Request  for  Nomenclature,  has 
been  processed  to  the  agreed  level  of  indenture. 

c.  Insure  that  approved  .nomenclature  has  been  reflected  in  the 
Development  and  Product  Specifications. 

d.  Identify  problems  associated  with  nomenclature  requests 
(DD-61s)  together  with  status  of  actions  towards  resolving 
the  problems. 


Insure  that  a  software  inventory  numbering  system  has  been 
agreed  to  and  implemented  to  the  CSCI  level. 


5 0 . 1 1  Value  Eno ineerinq  ( VE ) 

50.11.1  Review  status  of  all  VECPs  presented  per  the  terms  of  the 
contract . 


50.11.2  Review  any  new  areas  of  potential  value 
considered  profitable  to  challenge. 


Engineering 
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50.11.3  If  required  by  contract  (funded  ve  program),  review  the 
actual  Value  Engineering  accompl ishments  against  the  planned  VE 
program. 

50.12  Transoortabi 1 itv 

50.12.1  Review  transportability  evaluations  accomplished  for  those 
items  identified  as  outsized,  overweight,  sensitive,  and/or 
requiring  special  temperature  and  humidity  controls. 

50.12.2  Review  actions  taken  as  a  result  of  the  above'  evaluation 
to  insure  adequate  facilities  and  military  or  commercial 
transporting  equipment  are  available  to  support  system 
requirements  during  Production  and  Deployment  Phases. 

50.12.3  Review  design  of  special  materials  handling  equipment, 
when  required,  and  action  taken  to  acquire  equipment. 

50.12.4  Insure  DOD  Certificates  of  Essentiality  for  movement  of 
equipment  have  been  obtained  for  equipment  exceeding  limitations 
of  criteria  established  in  contract  requirements. 

50.12.5  Insure  transportabi 1 ity  approval  has  been  annotated  on 
design  documents  and  shall  remain  as  long  as  no  design  changes  are 
made  that  modify  significant  transportability  parameters. 

50.12.6  Identify  equipment  to  be  test  loaded  for  air 
transportabi 1 ity  of  material  in  Military  Aircraft. 

50.13  Test 

50.13.1  Review  updating  changes  to  all  specifications  subsequent 
to  the  PDR ,  to  determine  whether  Section  *4.0  of  the  spec i f i cat  ions 
adequately  reflects  these  changes. 

50.13.2  Review  all  available  test  documentation  for  currency, 
technical  adequacy,  and  compatibility  with  Section  4.0  of  all 
Specification  requirements. 

50.13.3  For  any  development  model,  prototype,  .etc.,  on  which 
testing  may  have  been  performed,  examine  test  results  for  design 
compliance  with  hardware  Development,  Software  Requi cements ,  and 
Interface  Requirements  Specification  requirements. 

50.13.4  Review  qualify  assurance  provicions/guai i f ication 
requirements  in  HWCI  Product,  Software  Requirements ,  or  Interface 
Requirements  Speci f icat ions  for  completeness  and  technical 
adequacy.  Section  4.0  of  these  specifications  shall  include  the 
minimum  requirements  that  the  item,  materiel,  or  process  must  meet 
to  be  acceptable. 

50.13.5  Review  all  test  documentation  required  to  support  test 
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requirements  of  Section  4.0  of  HWCI  Product  Specif icat ions  tar 
compatibility,  tech: ical  adequacy,  and  completeness. 

50.13.6  Inspect  any  breadboards,  aaockups,  or  prototype  hardware 
available  for  test  program  implications. 


50.13.7  Review  Software  Test  Descriptions  to  ensure  they  are 
consistent  with  the  Software  Test  Plan  and  they  thoroughly 
identify  necessary  parameters  and  prerequis i tes  to  enable 
execution  of  each  planned  software  test  and  monitoring  of  test 
results.  As  a  minimum,  test  descriptions  shall  identify  the 
following  for  each  test: 


a.  Required  preset  hardware  and  software  conditions  and  the 
necessary  input  data,  including  the  source  for  all  data. 

b.  Criteria  for  evaluating  test  results. 


c.  Prerequisite  conditions  to  be  established  or  set  prior  to 
test  execution. 


d.  Expected  or  predicted  test  result?. 

50.14  Maintenance  and  Maintenance  Data 

50.14.1  Review  adequacy  of  maintenance  plans. 

50.14.2  Review  status  of  unresolved  maintenance 
data  problems  since  the  PDR. 


and  maintenance 


50.14.3  Review  status  of  compliance  with  Data  Item  titled 
"Reliability,  Maintainability  Data  Reporting  and  Feedback.  Failure 
Summery  Reports." 


50.15  Spare  Parts  and  Government  Furn i rhed  Property  ( GFP ) . 

50.15.1  Review  provisioning  planning  through  normal  logistics 
channels  and  Administrative  Contracting  Officer  (ACO) 
representative  (Industrial  Specialist)  to  insure  its  compatibility 
(content  and  time  phasing)  with  contractual  requirements  (date  and 
SOW  items).  The  end  objective  is  to  provision  by  a  method  which 
shall  insure  system  support abi 1 ity  at  operational  date  of  the 
first  site.  Also  accomplish  the  following: 


a.  Insure  contractor  understanding  of  contractual  requirements, 
including  time  phasing,  instructions  from  logistics  support 
agencies,  interim  release  authority  and  procedure,  and 
responsibility  to  deliver  spare/repair  parts  by  need  cate. 


b. 


Determine  that  scheduled  provisioning  actions, 
guidance  meetings,  interim  release  and  screening, 
accomplished  adequately  and  on  time. 


such  as, 
are  being 
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c.  Identify  existing  or  potential  provisioning  problems. 

50.15.2  Determine  quantitative  and  qualitative  adequacy  of 
provisioning  drawings  and  data.  Verify  that  Logistics  Critical 
items  are  listed  for  consideration  and  that  adequate  procedures 
exist  for  reflecting  design  change  information  in  provisioning 
documentation  and  Technical  Orders. 

50.15.3  Insure  support  requirements  have  been  determined  for 
installat ion ,  checkout ,  and  test  for  approval  by  contracting 
agency.  Insure  screening  has  been  accomplished  and  results  are 
included  into  support  requirements  lists. 

50.15.4  Determine  that  adequate  storage  space  requirements  have 
been  programmed  for  on-site  handling  of  Installation  and  Checkout 
(ISC),  test  support  material,  and  a  scheme  has  been  developed  for 
"down  streaming"  and  joint  use  of  insurance  (high  cost)  or 
catastrophic  failure  support  items. 

50.15.5  Assure  that  Acquisition  Method  Coding  (AMC)  is  considered. 
50 . 16  Paekaqinq/SDPE 

50.16.1  Review  proposed  package  design  to  insure  that  adequate 
protection  to  the  HWCI ,  and  the  medi »  on  which  the  CSCI  is 
recorded,  is  provided.  against  n  itural  and  induced 
environments/hazards  to  which  the  equi.aaent  will  b*  subjected 
throughout  its  life  cycle ^  and  to  insuie  compliance  with 
contractual  requirements.  Such  analysis  shall  include,  but  not  be 
limited  to,  the  following: 

a.  Methods  of  preservation 

b.  Physical/mechanical/snock  protection  including  cushioning 
media,  shock  mounting  and  isolation  features,  load  factors, 
support  pads,  cushioning  devices,  blocking  and  bracing,  etc. 

c.  Mounting  facilities  and  secur ing/ho Id-down  provisions 

d .  Interior  and  ex  terior  container  designs. 

e.  Handling  provisions  and  compatibility  with  aircraft 
material, s  handling  system  (463L) 

f.  Container  marking 

g.  Consideration  and  identification  of  dangerous/hacardcus 
commodities 

50.16.2  Review  design  of  5DPE  HWCI  to  determine  if  a  category  I 
container  is  required.  The  analysis  of  the  proposed  container  or 
handling,  shipping  equivalent  shall  encompass  as  a  m;’iimum. 
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a.  Location  and  type  of  internal  mounting  or 
provis ions 


attaching 


b.  Vibration  -  shock  isolation  features,  based  on  the 
pre-dstermined  fragility  rating  (or  other  constraint  of  the 
item  to  be  shipped.) 


c.  Service  items  (indicators,  relief  valves,  etc.) 


d.  Environmental  control  features 


e.  External  handling,  stacking  and  tie-dowr.  provisions  vith 
stress  ratings 


f.  Dimensional  and  weight  data  (gross  and  net) 

g.  Bi 11-of-mater ial 


h.  Marking  provisions  including  the  center-of -grav i ty  location 


i . 


i  • 


For  wheeled  SDPE  (self-powered  or  tractor/trailer)  the 
overall  length,  width,  and  height  with  mounted  item,  turning 
radius,  mobility,  number  of  axles,  unit  contact  load,  number 
of  tires,  etc. 


Position  and  travel  of  adjustable  wheels,  titling,  or 
adjustments  to  facilitate  loading. 


50.16.3  Review  the  results  of  trade  studies,  engineering  analyses, 
etc. ,  to  substantiate  selected  package/SDRE  design  approach, 
choice  of  materials,  handling  provisions,  environmental  features, 
etc. 


50.16.4  Insure  that  package/SDPE  design  provides  reasonaole 
balance  between  cost  and  desired  performance. 

50 . 16 . 5 -Rev i ew  all  preproduction  test  results  of  the  prototype 
package  design  to  insure  that  the  HWCI  is  afforded  the  proper 
degree  of  protection. 

50.16.6  Review  Section  5,  Packaging,  of  the  HWCI  Product 
Specification  for  correct  format,  accuracy  and  technical  adequacy. 

50.16.7  Review  contractor  procedures  to  assure  that  the 
requirements  of  Section  5,  Preparation  for  Delivery  of  the 
approved  HWCI  Product  Specification,  will  be  incorporated  into  the 
package  design  data  for  provisioned  scares. 

50.17  Svstam  Alloc  at  ion  Document 

50.17.1  Review  maintenance  of  the  System  Allocation  Document  since 
PDF. .  a 
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50.17.2  Insure  plans  are  initiated  for  configuration  item 
re-allocations  that  may  be  necessary  due  to  actions  occurring 
prior  to,  or  during,  CDR. 

30.15  Design  Proriucibi 1 ity  and  Manufacturing 

5C.18.1  Review  the  status  of  ell  producibil ity  (and  productivity) 
efforts  for  cost  and  schedule  considerations. 

50.13.2  Review  the  status  of  efforts  to  resolve  manufacturing 
concerns  identified  in  previous  technical  reviews  and  their  cost 
and  schedule  impact  to  the  production  program. 

50.18.3  Review  the  status  of  Manufacturing  Technology  programs  one 
other  previously  recommended  actions  to  reduce  coot,  manufacturing 
risk  and  industrial  base  concerns. 

50.18.4  Identify  open  manufacturing  concerns  that  require 
additional  direction/effort  to  minimize  risk  to  the  production 
program. 

50. IB- 5  Review  the  status  of  manufacturing  engineering  efforts, 
tooling  and  test  equipment  demonst rat  ions ,  proofing  ox  new 
materials,  processes,  methods,  ar.d  special  tool  ir.g/test  equipment. 

50.18,6  Review  the  intended  manufacturing  management  system  and 
organization  for  the  production  program  in  order  to  show  how  their 
efforts  will  effect  a  smooth  transition  into  production. 

50.19  Post  Rev i e v  Act  ion 

50.19.1  After  completing  tne  CDR,  the  contractor  shall  publish  and 
distribute  copies  of  Review  minutes.  The  contracting  agency 
officially  acknowledges  completion  of  a  CDR  as  indicated  in 
paragraph  4.2.4. 

50.19.2  The  ac  . ompl ishment  of  the  CDR  shall  be  recorded  on  the 
configuration  item  Development  Record  by  the  contractor. 
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£0 .  Test  Readiness  Rev i cv  (TRR) . 

60.1  General .  Tine  TRR  shall  be  a  formal  review  of  the 
contractorr5  readiness  to  begin  formal  CSCI  testing.  It  is 
conducted  after  software  test  procedures  are  available  and  CSC 
integration  testing  is  complete.  The  purpose  of  TRR  is  for  the 
contracting  agency  to  determine  whether  the  contractor  is  in  fact 
ready  to  begin  CSCI  testing.  A  technical  understanding  shall  be 
reached  on  the  informal  test  ’■esuits,  and  on  the  validity  and  the 
degree  of  completeness  of  the  Computer  System  Operator's  Manual 
CCSOM),  Software  User's  Manual  (SUM),  and  Computer  System 
Diagnostic  Manual  (CSOM) . 

60.2  Items  to  be  rev  jewed.  The  contractor  shall  present  the 
following  for  reviet: 

60.2.1  Requirements  changes.  Any  changes  to  the  Software 
Requirements  Spec  i  f  i  ca  t'ion  or  Interface  Requirements 
Spec! f ication( s )  that  have  been  approved  since  SSR,  and  which 
impact  CSCI  testing. 

60.2.2  Design  cnanqes .  Any  changes  to  the  Software  Top-T.evel 
Design  Document,  Software  Detailed  Design  Document,  Data  Base 
Design  Document (s) ,  or  Interface  Design  Documcnt(s)  that  have  been 
made  sines  PDR  and  CDR,  and  which  impact  CSCI  testing. 

60.2.3  Software  test  plans  and  descriptions .  A  t.y  changes  to 
approved  Software  Test  Plans  and  Software  ’i’est  Descr ipt ions . 

60.2.4  Software  test  procedures .  Test  procedures  to  be  used  in 
conducting  CSCI  testing,  including  retest  procedures  for  test 
anomalies  and  corrections. 

60.2.5  CSC  integrat ion  test  cases .  procedures ,  and  results .  CSC 
integration  test  cases  and  procedures'  used  Tn  conducting  informal 
CSC  integration  tests  and  the  test  results. 

60.2.6  Software  test  resources ■  Status  of  the  development 
facility  hardware ,  Government  Furnished  Software  (GFS),  test 
personnel,  *cnd  supporting  test  software  and  ^materials,  including 
software  test  tool  qualification  end  review  of  the  traceability 
between  requirements  and  their  *  -ciated  tests. 

60.2.7  Test  1  imitations.  Identification  of  all  software  test 
1 imi tat  ions . 

60.2.8  Sot tvare  problems .  Summary  of  software  problem  status 
including  afl-  known  discrepancies  of  the  CSCI  and  test  support 
software . 

60.2.9  Schedules .  Schedules  for  remaining  milestones. 
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60.2.10  Documentat  ion  Updates.  Updates  to  all  evolving  9 
previously  delivered  CDRL  items  (e.g.,  CSCM,  SUM,  CSDM) . 

50.3  Post  Rev iev  Action, 

60.3.1  After  completing  the  TRR,  the  contractor  shall  publish  and 
distribute  copies  of  Review  Minuses.  The  contracting  agency 
officially  acknowledges  completion  of  a  TRR  as  indicated  in 
paragrapn  4.2.4. 


60.3.2  The  accomplishment  of  the  TRR  shall  be  recorded  on 
configuration  item  Development  Record  by  the  contractor . 
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70.  Fun:: tonal  Con f i qurat ion  Aud i t . 

70.1  General .  The  objective  of  the  Functional  Configuration  Audit 
(FCA)  shall  be  to  verify  that  the  configuration  item's  actual 
performance  complies  vith  its  hardware  Development  or  Software 
Requirements  and  Interface  Requirements  Spec i f icet ions .  Test  data 
snail  be  reviewed  to  verify  that  the  hardware  or  computer  software 
performs  as  required  by  its  functional/allocated  Configuration 
identification.  For  configuration  items  developed  at  Government 
expense,  an  FCA  shall  be  a  prerequisite  to  acceptance  of  the 
configuration  item.  For  software,  a  technical  understand ing  shall 
be  reached  on  the  validity  and  the  degree  of  completeness  of  the 
Software  Test  Reports,  and  as  appropriate.  Computer  System 
Operator's  Manual  (CSOM),  Software  User's  Manual  (SUM),  and 
Computer  System  Diagnostic  Manual  (CSDM). 

70.1.1  The  FCA  for  a  complex  configuration  item  may  be  conducted 
on  a  progressive  basis,  when  so  specified  by  the  contracting 
agency,  throughout  the  configuration  item's  development  ^nd 
culminates  at  the  completion  of  the  qualification  testing  of  the 
configuration  item  with  a  review  of  all  d  iscrepanc i es  at  the  final 
FCA.  The  FCA,  shall  be  conducted  on  that  configuration  of  the 
configuration  item  which  is  representative  (prototype  or 
preprbduct ion )  of  the  configuration  to  be  released  for  production 
of  the  operational  inventory  quantities.  Vhen  a  prototype  or 
preproduction  article  is  not  produced,  the  FCA  shall  be  conducted 
on  a  first  production  article.  For  cases  where  configuration  item 
qualification  can  only  be  determined  through  integrated  system 
testing,  FCA's  for  such  configuration  items  will  not  be  considered 
complete  until  completion  of  such  integrated  testing. 

70.1.2  Recommendations  of  configuration  item  acceptance  or 
non-acceptance  to  the  local  contract  management  agency  are  based 
upon  and  governed  by  procedures  and  requirements  outlined  in 
subsequent  paragraphs. 

70.2  Contract  Requ i rencnts 

70.2.1  The  schedules  for  the  FCA  shall  be  recorded  on  the 
configuration  item  development  record  by  the  contractor.  A 
configuration  item  cannot  be  audited  without  the  contracting 
agency  authentication  of  the  functional  and  allocated  baseline. 
Ir.  addition,  the  contractor  shall  submit  the  final  draft  Product 
Specification  for  the  configuration  item  to  be  audited  to  the 
contracting  agency  for  review  prior  to  FCA. 

70.3  Contractor  Kespor.s  i  b  i  1  i  tv 

70.3.1  Prior  to  the  FCA  date  (for  ccnf icurat ion  items  to  be 
audited) ,  the  contractor  shall  provide  the  following  information 
to  the  contracting  agency  (this  information  shall  be  provided  in 
addition  to  the  general  requirements  of  Section  4.): 
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a. 


Contractor  representation  (the  test  manager  should  be 
attendance). 


in 


b.  Identification  of  items  to  be  audited; 

(1)  Nomenclature 

(2)  Specification  identification  number 

(3)  Configuration  Item  number 

(4)  Current  listing  of  all  deviations/waivers  against  the 
configuration  item,  either  requested  of,  or  approved  by 
the  contracting  agency. 

(5)  Status  of  Test  Programs  to  test  configured  items  with 
automatic  test  equipment  (v.ien  applicable). 

7 0 . 4  Procedures  and  Rerm  i  r  emen ts 

70.4.1  The  contractor’s  test  procedures  and  results  shall  be 
reviewed  for  compliance  with  specification  requirements. 

70.4.2  The  following  testing  information  shall  be  available  feea. 

the  FCA  team.  MS 

a.  Tost  plans,,  specifications,  descriptions,  procedures,  and 
report*  for  the  configuration  item. 

b.  A  complete  list  of  successfully  accomplished  functional 
tests  during  which  pre-acceptance  data  was  recorded. 

c.  A  complete  list  of  successful  functional  tests  if  detailed 
test  data  are  not  recorded. 

d.  A  complete  list  of  functional  tests  required  by  the 
specification  but  not  yet  performed.  (To  be  performed  as  a 
system  or  subsystem  test). 

e.  Preproduction  and  production  test  results 


70.4.3  Testing  accomplished  with  the  approved  test  p<*ocedux*es  and 
validated  data  (witnessed)  shall  be  sufficient  to  insure 
configuration  item  performance  as  set  forth  in  the  specification 
Section  3  and  meet  the  quality  assurance  provisions/qualification 
requirements  contained  in  the  specification  Section  4. 

70.4.4  For  those  performance  parameters  which  cannot  completely  Dr 
verified  during  testing,  adequate  analysis  or  simulations  shall 
have  been  accomplished.  The  results  of  the  analysis  or 
simulations  will  be  sufficient  to  insure  configuration  icerf 
performance  as  outlined  in  the  specification.  " 
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70.4.5  Test  reports,  procedures,  end  data  used  by  the  FCA  team 
shall  be  made  a  matter  of  record  in  the  FCA  minutes. 

70.4.6  A  list  of  the  contractor's  internal  doewnentat ion 
(drawings)  of  the  configuration  it?*m  shall  be  reviewed  to  insure 
that  the  contractor  has  documented  the  physical  configuration  of 
the  configuration  item  for  which  the  test  data  are  verified. 

70.4.7  Drawings  of  HWCI  parts  which  are  to  be  provisioned  should 
be  selectively  sampled  to  assure  that  test  data  essential  to 
manufacturing  are  included  on,  or  furnished  with,  the  drawings. 

70. £.8  Configuration  items  which  fail  to  pass  quality  assurance 
test  provis ions/qual i f *  cat  ion  requirements  are  to  be  analyzed  as 
to  the  cause  of  failure  to  pass.  Appropriate  corrections  shall  be 
made  before  a  configuration  item  is  subjected  to  a 

requalif icotion. 

70.4.9  a  checklist  shall  be  developed  which  identifies 

documentation  and  hardware  and  computer  software  to  be  available 
and  tasks  ts  be  accomplished  at  the  FCA  for  the  configuration 
item.  See  Pre-FCA  checksheet. 

70.4.10  Retests  or  additional  tests  shall  be  performed  to  assure 
compliance  with  paragraph  70.4.3. 

70.4.11  Acknowledge  accomplishment  of  partial  completion  of  the 

FCA  for  those  configuration  items  whose  qualification  is 

contingent  upon  completion  of  integrated  systems  testing. 

70.4.12  For  CSCIs  the  following  additional  requirements  shall 

apply: 

a.  The  contractor  shall  provide  the  FCA  team  with  a  briefing 
for  each  CSCI  being  audited  and  shall  delineate  the  test 
results  and  findings  for  each  CSCI.  As  a  minimum,  the 
discussion  shall  include  CSCI  requirements  that  were  not 
met,  including  a  proposed  solution  to  each  item,  an  account 
of  the  ECPs  incorporated  and  tested  as  well  as  proposed,  and 
a  general  presentation  of  the  entire  CSCI  test  effort 
delineating  problem  areas  as  well  as  accomplishments. 

b.  An  audit  of  the  formal  test  plans/descriptions/procedures 
shall  be  mace  and  compared  against  the  official  test  data. 
The  results  shall  be  checked  for  completeness  and  accuracy. 
Deficiencies  shall  be  documented  and  made  a  part  of  the  FCA 
minutes.  Completion  dates  for  all  discrepancies  shall  be 
clearly  established  and  documented, 

c.  An  audit  of  the  Software  Test  Reports  shall  be  performed  to 
validate  that  the  reports  are  accurate  and  completely 
describe -the  CSCI  tests. 
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d.  Ail  EC?s  that  have  been  approved  shall  be  reviewed  to  ensure 
that  they  have  been  technically  incorporated  and  verified. 

e.  Ail  updates  to  previously  delivered  documents  shall  be 
reviewed  to  ensure  accuracy  and  consistency  throughout  the 
documentation  set. 

f.  Preliminary  and  Critical  Design  Review  minutes  shall  be 
examined  to  ensure  that  all  findings  have  been  incorporated 
and  completed. 

g.  The  interface  requirements  and  the  testing  of  these 
requirements  shall  be  reviewed  for  CSCls. 

h.  Review  data  base  character ist ics ,  storage  allocation  data 
and  timing,  and  sequencing  characteristics  for  compliance 
with  specified  requirements. 

70.5  Post  Audit  Act  ions 

70.5.1  After  completion  of  the  FCA,  the  contractor  shall  publish 
and  distribute  copies  of  FCA  minutes.  The  contracting  agency 
officially  acknowledges  completion  of  the  FCA  as  indicated  in 
paragraph  4.2.4. 

70.5.2  The  accomplishment  of  the  FCA  shall  be  recorded  on  tbe^ 
configuration  item  Development  Record  by  the  contractor. 


74 


MIL-STD- 1521B 
APPENDIX  H 


80.  Physical  Conf iquration  Audit  ( PCA? 

80.1  General ■  The  Physical  Configuration  Audit  (PCA)  shall  be  the 
formal  examination  of  the  as-built  version  of  a  configuration  item 
against  its  design  documentation  in  order  to  establish  the  product 
baseline.  After  successful  completion  of  the  audit,  all 
subsequent  changes  are  processed  by  engineering  change  action. 
The  PCA  also  determines  that  the  acceptance  testing  requirements 
prescribed  by  the  documentation  is  adequate  for  acceptance  of 
production  units  of  a  configuration  item  by  quality  assurance 
activities.  The  PCA  includes  a  detailed  audit  of  engineering 
drawings,  speoif icat ions ,  technical  data  and  tests  utilized  in 
production  of  HWCIs  and  a  detailed  audit  of  design  documentation, 
listings,  and  manuals  for  CSCIs.  The  review  shall  include  an 
audit  of  the  released  engineering  documentation  and  quality 
control  records  to  make  sure  the  as-built  or  as-ccded 
configuration  is  reflected  by  this  documentation.  For  software, 
the  software  Product  Specification  and  Version  Description 
Document  shall  be  a  part  of  the  PCA  review. 

80.1.1  The  PCA  shall  be  conducted  on  the  first  article  of 
configuration  items  and  those  that  are  a  reprocurement  of  a 
configuration  item  already  in  the  inventory  shall  be  identified 
and  selected  jointly  by  the  contracting  agency  and  the  contractor. 
A  PCA  shall  be  conducted  on  the  first  configuration  item  to  be 
delivered  by  a  new  contractor  even  though  PCA  was  previously 
accomplished  on  the  first  article  delivered  by  a  different 
contractor . 

80.1.2  Formal  approval  by  the  contracting  agency  of  the 
configuration  item  Product  specification,  and  the  satisfactory 
completion  of  a  PCA  results  in  establishment  of  the  product 
baseline . 

80.1.3  Recommendations  of  configuration  item  acceptance  or 
nonacceptance  to  the  responsible  contract  adm i nstrat ion  office 
(CAO)  are  based  upon  and  governed  by  procedures  and  requirements 
outlined  in  subsequent  paragraphs. 

80.1.4  A  final  review  shall  be  made  of  all  operation  and  support 
documents  (i.e.t  Computer  System  Operator's  Manual  (CSOM), 
Software  User's  Manual  (SUM),  Computer  System  Diagnostic  Manual 
(CSDM),  Software  Programmer's  Manual  (SHM),  Firmware  Support 
Manual  (FSM))  to  check  format,  completeness,  and  conformance  with 
applicable  data  item  descriptions. 

80.2  Contract  Requirements 

30.2.1  The  schedules  for  the  PCA  shall  be  recorded  on  the 
configuration  item  Development  Record  by  the  contractor.  A 
current  set  of  listings  shall  be  provided  for  each  CSCI  being 
audited.  The  .contractor  shell  submit  the  final  draft  of  the 
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product  specification  for  the  configuration  item  to  be  audited  to 
the  contracting  agency  for  review  prior  to  PCA. 

80.3  Contractor  Responsibility 

80.3.1  The  contractor  shall  provide  the  following  information  to 
the  contracting  agency  {this  information  shall  be  provided  in 
accordance  with  the  general  instructions  of  Section  4  and  the 
contractual  requirements): 


a.  Contractor  representation  {the  .test  manager  should  be  in 
attendance ) . 


b. 


Identification  of  items  to  be  accepted  by: 

(1)  Nomenclature 

(2)  Specification  Identification  Number 
{3)  Configuration  item  Identifiers 

{4)  Serial  Numbers 

(S)  Drawing  and  Part  Numbers 

(fi)  Identification  Numbers 

(7)  code  Identification  Numbers 

(8)  Software  inventory  numbering  system 


A  list  delineating  all  devi at ions/va -vers  against  the 
"configuration  item  either  requested  or  contracting  agency 
approved. 


80.3.2  The  PCA  cannot  be  performed  unless  data  pertinent  to  the 
configuration  item  being  audited  is  provided  to  the  PCA  team  at 
time  of  the  audit.  The  contractor  shall  compile  3  make  this 
information  available  for  ready  reference.  Requij  information 
shall  include: 


a.  Configuration  item  product  specification. 

b.  A  list  delineating  both  approved  and  outstanding  changes 
against  the  configuration  item. 

c.  Complete  shortage  list. 


d. 


a. 


Acceptance  test  procedures 
Engineering  drawing  index 


and  associated  test  data, 
including  revision  letters. 
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f . 

Operating 
manuals . 

,  maintenance,  end  i 

1 lustrated  parts 

breakdown 

9* 

Proposed 
Report" . 

DD  Form  250,  "Material 

Inspection  and 

Receiving 

h. 

Approved 

nomenclature  and  nameplates. 

i . 

Software 

Programmer ' s  Manuals 

(SPMs),  Software 

User's 

Manuals  (SUMs)  Computer  Systerr.  Operator's  Manual  (CSOM), 
Computer  System  Diagnostic  Manual  (CSOM),  and  Firmware 
Support  Manual  (FSM). 

j.  Software  Version  Description  Document. 

k.  FCA  minutes  for  each  configuration  item, 

l.  Findings/Status  of  Quality  Assurance  Programs. 

BO.  3. 3  The  contractor  shall  assemble  and  make  available  to  the  PCA 
team  at  time  of  audit  all  data  describing  the  'item  configuration. 
Item  configuration  data  shall  include: 

a.  Current  approved  issue.  of  hardware  development 

specification.  Software  Requirements  Specification,  end 
Interface  Requirements  Spec i f icat ion (s)  to  include  approved 
specification  change  notices  and  approved 

deviat ions/wa ivers , 

b.  Identification  of  all  changes  actually  made  during  test. 

c.  Identification  of  all  required  changes  not  completed. 

d.  All  approved  drawings  and  documents  by  the  top  drawing 
number  as  identified  in  the  configuration  item  product 
specif icat ion.  All  drawings  shall  be  of  the  category  and 
fora  specified  in  the  contract. 

e.  Manufacturing  instruction  sheets  for  HWCIs  identified  by  the 
contracting  agency. 

80. 3c 4  The  contractor  shall  identify  any  difference  between  the 
physical  configurations  of  the  selected  production  unit  and  the 
Development  Unit(s)  used  for  the  FCA  and  shall  certify  or 
demonstrate  to  the  Government  that  these  differences  do  not 
degrade  the  functional  charaeterist ics  of  the  selected  units. 

80.4  PCA  Procedures  and  Requirements 

8C.4.1  Drawing  and  Manufacturing  Instruction  Sheet  Review 
Instruct  ions: 
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A  representative  number  of  drawings  and  associated 
manufacturing  instruction  sheets  for  each  item  of  hardware, 
identified  by  the  contracting  agency  Co-Chairperson,  shall 
be  reviewed  to  determine  their  accuracy  and  insure  that  they 
include  the  authorized  changes  reflected  in  the  engineering 
drawings  and  the  hardware.  Unless  otherwise  directed  by  the 
contracting  agency  Co-Chairperson,  inspection  of  drawings 
and  associated  manufacturing  instruction  sheets  may  be 
accomplished  or.  a  valid  sampling  basis.  The  purpose  of  this 
review  is  to  insure  the  manufacturing  instruction  sheets 
accurately  reflect  all  design  details  contained  in  the 
drawings.  Since  the  hardware  is  built  in  accordance  with 
the  manufacturing  instruction  sheets,  any  discrepancies 
between  the  instruction  sheets  and  the  design  details  and 
changes  in  the  drawings  will  also  be  reflected  in  the 
hardware . 


b.  The  following  minimum  information  shall  be  recorded  for  each 
drawing  reviewed: 


(1)  Drawing  number/title  {include  revision  letter) 


c . 


(2)  Date  of  drawing  approval 

(3)  List  of  manufacturing  instruction  sheets  (numbers  wii^B 
change  letter/titles  and  date  of  approval)  associat*^^ 
with  this  drawing. 

(4)  Discrepanc.ies/comments 

(5)  Select  a  sample  of  part  numbers  reflected  on  the 
drawing.  Check  to  insure  compatibility  with  the  Program 
Parts  Selection  List,  and  examine  the  HWCI  to  insure 
that  the  proper  parts. are  actually  installed. 

As  a  minimum,  the  following  inspections  shall  be 
accomplished  for  .each  drawing  and  associated  manufacturing 
instruction  sheets: 


(1)  Braving  number  identified  on  manufacturing  instruction 
sheet  should  match  latest  released  drawing. 

(2)  List  of  materials  on  manufacturing  instruction  sheets 
should  match  materials  identified  or  the  drawing. 

(3}  All  special  instructions  called  on  the  drawing  should  be 
on  the  manufacturing  instruction  sheets. 

(4)  All  dimensions,  tolerances,  finishes,  etc.,  called  out 
on  the  drawing  should  be  identified  on  the  m?  ,ufacturing 
instruction  sheets  M 
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(5)  All  special  processes  called  out  on  the  drawing  should 
be  identified  on  the  manufacturing  instruction  sheets. 

(6)  Nomenclature  descriptions,  part  numbers  and  serial 
number  markings  called  out  on  the  drawing  :  hould  be 
identified  on  the  manufacturing  instruction  sheets. 

(7)  Review  drawings  and  associated  manufacturing  instruction 
sheets  to  ascertain  that  all  approved  changes  have  been 
incorporated  into  the  configuration  item. 

<8)  Check  release  record  to  insure  all  drawings  reviewed  are 
identified. 

(9)  Record  the  number  of  any  drawings  containing  more  than 
five  outstanding  changes  attached  to  the  drawing. 

(10)  Check  the  drawings  of  a  major  assembly /black  box  of  the 
hardware  configuration  item  for  continuity  from  top 
drawing  down  to  piece-part  drawing. 

BO. 4. 2  Review  of  all  records  of  baseline  configuration  for  the 
HWCI  by  direct  comparison  with  contractor’s  engineering  release 
system  and  change  control  procedures  to  establish  that  the 
configuration  being  produced  does  accurately  reflect  released 
engineering  data.  '  This  includes  interim  releases  of  spares 
provisioned  prior  to  PCA  to  ensure  delivery  of  currently 
configured  spares. 

80.4.3  Audit  of  contractor's  engineering  release  and  change 
control  system  to  ascertain  that  they  are  adequate  to  properly 
control  the  processing  and  formal  release  of  engineering  changes. 
The  minimum  needs  and  capabilities  set  forth  below  art  required  of 
his  engineering  release  records  system.  The  contractor's  formats, 
systems,  and  procedures  are  to  be  used.  Information  in  addition 
to  the  basic  requirements  is  to  be  considered  part  of  the 
contractor’s  internal  system.* 


80.4.3.1  As  t»  ’minimum,  the  'following  information  shall  be 
contained  on  one  release  record  supplied  by  the  contractor, 
subcontractor ,  or  vendor  for*each  drawing -number ,  if  applicable: 

a.  Serial  numbers,  top  drawing  number,  specification  number; 

b.  Drawing  number,  title,  code  number,  number  of  sheets,  date 


*  Contract  Administration  Office  (CAQ)  Quality  Assurance 
Representat i ve  (QAR)  records  can  be  reviewed  for  purpose  of 
determining  the  contractor's  present  and  most  recent  past 
performance „ 
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of  release,  change  letter,  date  of  char-qe  letter  release* 
engineering  change  order  (ECO)  number. 

80.4.3.2  The  contractor's  release  function  and  documentation  will 
be  capable  of  determining: 

a.  The  composition  of  any  part  at  any  ivs-vel  ir.  terns  of 

subordinate  part  numbers  (disregard  standard  parts); 

b.  The  next  higher  assembly  using  the  part  number,  except  for 
assembly  into  standard  parts; 

c.  The  composition  of  the  configuration  item  or  part  number 
with  respect  to  other  configuration  items  or  part  numbers-; 

d.  The  configuration  item  and  associated  serial  .’iuoiowr  on  which 

subordinate  parts  are  used.  (Thii  does  not  apply  to 

contractors  beiov  prime  leval  who  are  not  producing 
configuration  items); 

e.  The  accountability  of  changes  which  nave  b>  .-n  partially  or 
completely  released  against  the  configuration  item; 

f.  The  configuration  item  and  serial  number  effectively  of  ex¬ 
change. 

g.  The  standard  speci f icat ion  numuer  or  standard  part  number™ 
used  within  any  nonstandard  part  number; 

h.  The  contractor  specification  document  and  specification 
control  numbers  associated  with  any  subcontractor ,  vendor, 
or  supplier  part  number. 

80.4.3.3  The  engineering  release  system  and  associated 
documentation  shall  be  capable  of: 

a.  Identifying  changes  and  retaining  records  of  superseded 
configurations  formally  accepted  by  the  contracting  agency; 

b.  Identifying  all  engineering  changes  released  for  production 
incorporation.  These  changes  shall  be  complete  y  released 
and  inr.  jrporated  prior  to  formal  acceptance  of  the 
configuration  item; 

c.  Determining  the  configuration  released  for  each 
configuration  item  at  the  time  of  formal  acceptance. 

80.4.3.4  Engineering  data  shall  be  released  or  processed  through  a 
central  authority  to  ensure  coordinated  action  and  preclude 
unilateral  release  of  data. 

80.4.3.5  Engineering  change  control  numbers  shall  be  unique,  jg 
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80.4.4  Difference  between  the  configuration  of  the  configuration 
item  qualified  *nd  the  configuration  item  being  audited  shall  be  a 
matter  cf  record  in  the  minutes  of  the  ?CA. 

80.4.5  For  HWCI  acceptance  tests  date  and  procedures  shall  comply 
with  its  product  specification.  The  PCA  team  shall  determine  any 
acceptance  tests  to  be  reaccomplished,  and  reserves  the 
prerogative  to  have  representatives  cf  the  contracting  aaency 
witness  all  or  any  portion  of  the  required  audits,  inspections,  or 
tests. 

80.4.6  HWCIs  which  fail  to  pass  acceptance  test  requirements  shall 
be  repaired  if  necessary  and  be  retested  by  the  contractor  in  the 
manner  specified  by  the  PCA  team  leader  in  accordance  with  the 
product  specification. 

80.4.7  The  contractor  shall  present  data  confirming  the  inspection 
and  test  of  subcontractor  equipment  end  items  at  point  of 
manufacture.  Such  data  shell  have  been  witnessed  by  Government 
representative. 

80.4.8  The  PCA  team  review*  the  prepared  back-up  d.ita  (all  initial 
documentation  which  accompanies  the  configuration  item)  for 
correct  types  and  quantities  to  ensure  adequate  coverage  at  the 
time  o£  shipment  to  the  user. 

80.4.5  Configuration  items  which  have  demonstrated  compliance  with 
the  product  specification  are  approved  for  acceptance  as  follows s 

&.  The  PCA  team  shall  certify  by  signature  that  the 

configuration  item  has  been  built  in  accordance  with  the 
drawings  and  specifications, 

80.4.10  As  a  minimum,  the  following  actions  shall  be  performed  by 
the  PCA  team  on  each  CSCI  being  audited: 

a.  Review  all  documents  which  will  comprise  the  Software 
Product  Specification  for  founat  and  completeness 

b.  Review  FCA  minutes  for  recorded  discrepant ies  and  actions 
taken 

c.  Review  ths  design  descriptions  for  proper  entries.  symbols, 
labels,  tags,  references,  and  data  descriptions. 

d.  Compare  Top-Level  Computer  Software  Component  (TLCSC)  design 
descriptions  with  Lower-Level  Computer  Software  Components 
( LLCSC )  descriptions  for  consistency 

e.  Compare  all  lover-level  design  descriptions  with  all 
software  listings  for  accuracy  and  completeness 
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f.  Check  Software  User's  Manual (5),  Software  Programmer^^ 
Manual,  Computer  System  Operator's  Manual,  Firmware  Support 
Manual,  and  Computer  System  Diagnostic  Manual  fcr  format 
completeness  and  conformance  with  applicable  data  item 
descr ipt ions.  (Formal  verification/acceptance  of  these 
manuals  should  be  withheld  until  system  testing  to  ensure 
that  the  procedural  contents  are  correct;) 

g.  Examine  actual  CSCI  delivery  media  (card  decks,  tapes, 
etc.,)  to  insure  conformance  with  Section  5  of  the  Software 
Requirements  Specification. 

h.  Review  the  annotated  listings  for  compliance  with  approved 
coding  standards  (e,g.  Appendix  C  of  DOD'-3VT>*21€7 ) , 

80.5  Post  Audit  Actions 

80.5.1  Contracting  agency  acceptance  or  rejection  of  the 
configuration  item  and  the  conf iguretion  item  product 
specification  presented  for  PCA  must  be  furnished  to  the 
contractor  in  writing  by  the  responsible  contract  management 
agency  or  other  designated  agency  after  completion  of  PCA, 

80.5.2  After  completion  of  the  PCA,  the  contractor  shall  publish 
and  distribute  copies  of  PCA  minutes.  The  contracting  agency 
officially  acknowledges  completion  of  the  PCA  cs  indicated  igEfe 
paragraph  4,2.4, 

80.5.3  The  atcompl ishmenr.  of  the  PCA  shall  be  recorded  on  the 
configuration  item  Development  Record  by  the  contractor. 
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90.  Formal  Quail f ication  Rev i ev . 

90.1  General .  The  objective  of  the  FQR  shall  be  to  verify  that 
the  actual  performance  of  the  configuration  items  of  the  system  as 
determined  through  test  comply  with  the  hardware  Development 
Specification,  Software  Requirements  and  interface  Requirements 
Specifications,  and  to  identify  the  test  report (s ) /data  which 
document  results  of  qualification  tests  of  the  configuration 
items.  The  point  of  Government  certification  will  be  determined 
by  the  contracting  agency  and  will  depend  upon  the  nature  of  the 
program,  risk  aspects  of  the  particular  hardware  and  software,  and 
contractor  progress  in  successfully  verifying  the  requirements  of 
the  configuration  items.  When  feasible,  the  FQR  shall  be  combined 
with  the  FCA  at  the  end  of  configuration  item/subsyste’Q  testing, 
prior  to  PCX.  If  sufficient  test  results  are  not  available  at  the 
FCA  to  insure  the  configuration  items  will  perform  in  their  system 
environment,  the  FQR  shall  be  conducted  (post  PCA)  during  System 
testing  whenever  the  necessary  tests  have  been  successfully 
completed  to  enable  certification  of  configuration  items.  For 
non- combined  FCA/FQRs ,  traceability,  correlation,  and  completeness 
of  the  FQR  shall  be  maintained  with  the  FCA  and  duplication  of 
effort  avoided. 

50 . 2  Requirements. 

yo.2.1  in  cases  where  the  FQR  and  the  FCA  can  be  accomol ished  in  a 
single  combined  Audit/Review,  contractor  and  ”  Government 
"certification"  Of  the  configuration  items  shall  be  accomplished 
after  completion  of  the  FCA  and  such  certification  shall  be 
considered  as  accomplishment  of  the  FQR. 

90.2.2  When  the  agency  responsible  for  qualification  of  the 
configuration  items  at  the  contracting  agency  judges  that  the 
system  is  not  ready  for  FQR, at  the  time  of  FCA,  the  FQR  will  be 
delayed  until  it  is  determined  that  sufficient  information  on  the 
system’s  qualification  is  available.  The  FQR  may  be  delayed  up  to 
the  end  of  System  testing  if  deemed  necessary. 

90.2.3  When  a  separate  FQR  is  necessary,  th®  contractor  shall 
notify  the  contracting  agency  of  the  sufficiency  of  the 
configuration  items  test  results  to  substantiate  a  FQR  and 
coordinate  the  agenda  with  the  Deputy  Director  for  Test  and 
Deployment.  The  FQF.  team  will  be  assembled  in  the  same  manner  as 
that  required  for  the  FCA  team.  No  duplication  of  FCA  effort 
shall  occur  at  the  FQR;  however,  the  following  additional  efforts 
must  be  accomplished: 

90.2.3.1  A  review  of  the  FCA  minutes  must  be  performed  and  the  FQR 
shall  be  considered  as  cn  extension  of  rCA.  N'ew/aodit  ional 
qualification  data  shall  be  audited  arid  reviewed  to  insure 
qualification  of  the  configuration  items  against  the 
System/Segment ,  Software  Requirements,  and  Interface  Requirements 
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90.2.3.2  Any  testing  accomplished  against  configuration  item 
qualification  during  System  testing  shall  be  considered. 

90.2.3.3  The  contractor  shall,  after  notification  of  certification 
by  the  contracting  agency  enter  the  date  of  system  certification 
of  qualification  and  the  identity  of  the  test 
reports/documentation  vhich  sots  forth  the  results  of  the 
associated  test(s)  in  the  configuration  item  Development  Record. 

90.2.4  All  other  factors  such  as:  agenda.  team  organization, 
reviev  procedures,  data  to  be  reviewed,  etc.,  shall  be 
accomplished  as  delineated  in  the  TCA  and  General  Requirements  and 
Procedures  sections  of  this  standard  to  the  extent  necessary  to 
accomplish  the  FQR. 


90.3  Post  Review  Action 

90.3.1  After  the  conduct  of  the  FQR,  the  contractor  shall  publish 
and  distribute  copies  of  FQR  minutes.  The  contracting  agency  will 
officially  acknowledge  the  conduct  of  the  Review  as  indicated  in 
paragraph  4.2.4. 
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SAMPLE  CERTIFICATION  ATTACHMENT 


PRE-FCA  CHECK  SHEET 


NOMENCLATURE  _________ 

CONFIGURATION  ITEM  NO. 


CONTRACTOR  REQUIREMENTS 


Wai ver/Deviaticn  List  Prepared 

Qualification  Test  Procedures  Submitted 

Qualification  Testing  Completed 

Qualification  Test  Results  Compiled  & 
Available 

Facilities  for  Conducting  FQA  Available 

Qualification  Test  Procedures  Reviewed 
and  Approved 

Qualification  Testing  Witnessed 

Qualification  Test  Data  and  Results 
Reviewed  and  Approved 


COMMENTS 


DATE 


X£S 


Figure  3 
Page  1  of  11 
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SAMPLE  CERTIFICATION  ATTACHMENT 


FPNCTIONA". 


r : 


CONFIGURATION  ITEM  NC.  (Si 
CONTRACT  NO .  - 


PRIME  CONTRACTOR: 


EQUIPMENT  MANUFACTURERS: 


APPROVED  BY  _ _  APPROVED  BY 

( CONTRACTOR  )  T&ONTJtACl' TnS"  AGENC7T 


DATE 


DATE 


Figure  3 
Page  2  of  1). 
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DEFINITIONS: 

COMMENT:  A  note  explaining,  illustrating,  or  criticiring  the 
meaning  of  a  writing.  Items  c£  tnis  nature  should  he  explored 
by  the  contractor  and/or  the  Contracting  Agency,  out  corrective 
action  is  NOT  necessary  to  successfully  accomplish  a  FCA. 

DEFICIENCY:  Deficiencies  consist  of  two  types:  ill  conditions 

of  characteristics  in  any  hardware/ software  wnicti  are  not  in 
compliance  with  specified  configuration,  or  (2)  inadequate  (or 
erroneous)  configuration,  identification  wnicn  has  resulted,  or 
may  result  in  configuration  items  that  do  not  fulfill  approved 
operational  requirements. 


Figure  3 
Page  3  of  11 
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SCOPE/PURPOSE 


Scope : 

Functional  Configuration  Audit  (FCA)  was  conducted  on  tne  following 
configuration  item: 

Configuration  Item  No,  Nomenclature  Part  No ♦  Serial  No . 

PURPOSE :  The  purpose  of  this  FCA  was  to  verify  that  the  configuration 

item' s  performance  complies  with  the  Type  B  Development  Specif i cation . 


Figure  3 
Page  4  of  11 


68 


MXL-5TD-1521B 
APPENDIX  I 


j3aariiPHftL,.gagifiiaAi;py  Mam 

CERTIFICATION  SHEET  NO,  1 
(For  Equipment/Cotnputer  Software ) 


Contract: _ Date 


Contractor: 


Configuration  Item  No.: 


Qualification  Test  Procedures  and  Results.  The  qualification  test/ 
analysis  results  have  been  reviewed  to  ensure  that  testing  is  adequa 
properly  done,  and  certified.  (All  test  procedures  and  interface 
documents  shall  be  reviewed  to  assure  that  the  documents  have  been 
approved  by  the  Contracting  Agency.  All  test  data  sheets  shall  be 
reviewed  to  assure  that  the  test  was  witnessed  by  »  representative  o 
the  Contracting  Agency.) 

Attached  is  a  list  of  the  documents  reviewed. 

Check  One 


Procedures  and  results  reviewed  satisfy  the  requirements  and 
are  accepted.  See  Attachment  _  for  comments. 

Attached  is  a  list  of  deficiencies. 

Signatured  )  of  FCA  Team  Member!  s) 


W£ub-Team  Chairperson 


Figure  3 
Page  5  of  11 
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Figure  3 
Page  7  of  11 
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FUNCTIONAL  CONFIGURATION  AUDI? 

CERTIFICATION  SHEET  NO.  2 
(For  Equipment/Computer  Software) 

Contract:  Date 

Contractor :  _ 

Configuration  Item  No. : _ 


Review  Deviation?; /Wa ivers .  A  review  of  all  deviations/waivers  to 
military  .specifications  and  standards  that  have  been  approved.  The 
purpose  is  to  determine  the  extent  to  which  the  equipment ( s ) /computer 
software  undergoing  FCA  vary  from  applicable  specifications  and 
standards  and  to  form  a  basis  for  satisfactory  compliance  with  these 
specifications  and  standards. 


In  accordance  with  this  paragraph,  all  applicable 
have  been  reviewed  with  the  following  results: 


deviations /waive 


Chech  One 

|  }  The  equipment f s ) /computer  software  listed-  on  Certification 
Sheet  No.  1  of  this  report  complies  with  all  applicable 
specifications  and  standards.  See  Attachment  _ _  for  comments. 

□  Attached  is  a  list  of  discrepancies  and/or  comments. 

Signature! 3)  of  FCA  Team  Member fs ) 


•Sub-Team  Chairperson 


Figure  3 
Page  8  of  11 
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A.  Deviution/Waiver  Rev lev  Team  Instructions.  All  approved 
waivers  and  deviations  to  military  specifications  and  standards 
shall  be  reviewed  and  recorded.  Also,  record  any  part  of  the 
FCA  which  fails  to  meet  specifications  or  standards  but  is  not 
an  approved  waiver/deviation. 

B.  Results  of  Team  Review.  List  v.he  deviations/waivers  against 
the  equipment /computer  software  being  FCA'd  that  were  reviewed. 


Figure  3 
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WAIVERS/DEVIAT IONS 


MX1-STD-152IB 
APPENDIX  3 


SAMPLE  CERTIFICATION  ATTACHMENT 

FORMAL  QUALIFICATION  REVIEW 
(For  oquxpment/Computer  SoTtw&re) 

Contract:  _  Date 

Con  tr  a  c  tor : _ 

Configuration  Item  No.:  _ 


Formal  Qualification  Review.  Qualification  Test/Analysis  results 
have 'been  revIeweB  to  verify  that  the  actual  performance  of  the 
configuration  item  complies  with  its  development  or  requirements 
specif ication ( s )  and  that  sufficient  test  results  are  available  to 
ensure  the  configuration  item  will  perform  in  its  system  environment . 

Attached  is  a  list  of  the  documents  reviewed. 

Check  One 


f"j  Results  reviewed  .satisfy  FQR  'requirements  and  the  configuration 
*■“*  item  is  qualified  for  entry  into  the  Government  Inventory. 

r-i  Results  reviewed  are  unsatisfactory/insufficient  for  FQR.  FQR 
will  be  delayed  until  it  is  determined  that  sufficient 
information  on  the  configuration  items  Qualification  is  available. 

Signature(s)  of  FCA.  Team  Member! s) 


Figure  3 
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SAMPLE  CERTIFICATION  ATTACHMENT 
SAMPLE  PCA  CHECKLIST 


The  following  hardware,  computer  software,  documentation  shall  be 
available,  and  the  following  tasks  shall  be  accomplished  at  the 
PCA. 


Hardware : 


Computer  Software: 


Documentation : 


(1)  Approved  final  draft  of  the  configuration  item 
proiuet  specification. 

(2)  A  list  delineating  both  approved  and  outstanding 
changes  against  the  configuration  item. 

(3)  Complete  shortage  list. 

(4)  Acceptance  test  procedures  and  associated  test 
data . 

(5)  Engineering  Drawing  Index. 

(6)  Operating,  maintenance,  and  illustrated  parts 
breaKdown  manuals. 

(7)  List  of  approved  material  review  board  actions 
on  waivers, 

(8)  Proposed  DD  Form  250,  "Material  Inspection  and 
Receiving  Report". 

(9)  Approved  nomenclature  and  nameplates. 

(10)  Manuscript  copy  of  ail  CSCI  manuals. 

(11)  Computer  Software  Version  Description  Document. 

(12)  Current  set  of  listings  and  updated  design 
descriptions  or  other  means  of  design  portrayal 
for  each  CSCI. 

(13)  FCA  minutes  for  each  configuration  item. 


Figure  4 
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Tasks 

(1) 

(2) 

(3) 

(4) 

(5) 

(6) 

(7) 

(8) 

(9) 
(10  ) 


(11) 


(12) 

(13) 


MlL-STfc-lSlig 
APPENDIX  I 


SAMPLE  CERTIFICATION  ATTACHMENT 
SAMPLE  PCA  CHECKLIST  (CONTINUED) 


Yes  No 


Define  Product  Baseline. 

Specification  Review  and  Validation. 

Drawing  review. 

Review  acceptance  test  procedures  and  results. 
Review  shortages  and  unincorporated  design 
changes . 

Review  deviations/waivers. 

Examine  proposed  DD  250. 

Review  c.ontractor '  s  Engineering  Release  and 
Change  Control  System. 

Review  system  allocation  document. 

Review  Software  user's  Manuals,  Software 
Programmer  * s  Manuals,  Computer  System  Diagnostic 
Manual,  Computer  System  Operator's  Manual,  and 
Firmware  Support  Manual. 

Review  CSCIs  for  the  following: 

(a)  Top-level  and  lower-level  Computer  Software 
Component  design  descriptions  or  alternative 
design  portrayals. 

(b)  Top-level  and  lower-level  Computer  Software 
Component  interface  requirements. 

(c)  Data  base  characteristics,  storage  alloca¬ 
tion  charts  and  timing  and  sequencing 
characteristics . 

Review  packaging  plan  and  requirements. 

Review  status  of  Rights  in  Data. 


Figure  4 
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SAMPLE  CERTIFICATION  ATTACHMENT 
PHYSICAL  CONFIGURATION  AUDIT  ( PCA ) 
FOR 

CONFIGURATION  ITEM  NO.(s)  _ 

CONTRACT  NO-  _ 


PRIME  CONTRACTOR:  EQUIPMENT  MANUFACTURERS: 


APPROVED  BY  (DESIGNEE) 
CONTRACTOR 


APPROVED  BY 


(DESIGNEE) 


CONTRACTING  AGENCY 


DATE 


DATE 


Figure  4 
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DEFINITION  OF  TERMS 


COMMENT  -  a  note  explaining,  illustrating,  or  criticizing  the 
meaning  of  a  writing.  Items  of  this  nature  should  he  explored 
by  the  contractor  and/or  the  Contracting  Agency,  but  corrective 
action  is  NOT  necessary  to  successfully  accomplish  a  PCA. 

DISCREPANCY  -  A  not  explaining,  illustrating,  or  criticizing  the 
difference  between  writings,  a  note  showing  the  variance  between 
what  exists  and  what  is  acceptable.  Items  of  this  nature  shall 
be  rectified  by  the  contractor  prior  to  successful  accomplishments 
of  a  PCA. 


Figure  4 
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SCOPE /PURPOSE 


A  Physical  Configuration  Audit  (PCA)  was  conducted  on  the 
following  end  items  of  eguipment/computer  software: 

CONFIGURATION  ITEM  NOMENCLATURE  PART  NUMBER  SERIAL  NO.  NSN 


The  purpose  of  the  PCA  was  to  ensure  accuracy  of  the  identifying 
documentation  and  to  establish  a  product  baseline. 

The  establishment  of  a  product  baseline  for  eguipment/computer 
software  is  not  to  be  construed  as  meeting  Contracting  Agency 
requirements  for  delivery  by  the  contractor  of  an  operational 
system  meeting  approved  acceptance  criteria. 


Figure  4 
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fSYSXCftl.  COWTIggRATIPN  tViajIT 

CERTIFICATION  SHEET  NO.  1 
(For  Equipment/Computer  Software) 


Contracts  Date 


Contractor : 


Product  baseline.  The  following  documents  of  the  issue  and  date 
shown  comprise  the  product  baseline  for  the  listed  equipment ( s ) / 
computer  software: 


EQPT . /COMP . 

ASSEMBLY  TOP  SOFTWARE  CONFIGURATION 

SPEC  NO.  DRAWING  NO.  ISSUE  NOMENCLATURE  ITEM  NO. 


Signature(s)  of  PCA  Team  Member(s) 


*  * 


* 


#*Team  Chairperson 
*Sub-Team  Chairperson 


Figure  4 
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PHYSICAL  CONFIGURATION  AUDIT 

CERTIFICATION  SHEET  NO.  2 
(For  Equipment/Computer  Software) 


9 


Contract.:  Date 


Contractor : 


Specification  Review  and  Validation.  Specifications  have  been 
reviewed  and  validated  to  assure  that  they  adequately  define  the 
configuration  item  and  the  necessary  testing,  moLil i ty /transpor¬ 
tability,  and  packaging  requirements. 

Check  One 


The  Type  C  Specifications  are  complete  and  adequately 
define  the  configuration  iter. .  They  shall,  therefore, 

constitute  the  product  baseline.  See  Attachment  _  for 

comments . 


D 


The  Type  C  Specif ications  are  unacceptable.  Attached  is  a 
list  of  discrepancies. 


Signature(s)  of  FCA  Tear  Member! s) 


* 


*Sub-Team  Chairperson 
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A •  Specif icacion  Review  ana  Validation  Instructions .  The 
detailed  specif icaticns  listed  in  paragraph  §eTow  shall 
be  reviewed  for  compliance  with  the  applicable  requirements. 
Each  Specification  shall  serve  as  the  basic  document  for 
configuration  control  of  the  subject  configuration  items. 

The  information  contained  within  the  specifications  shall  be 
audited  at  the  PCA . 

B .  Review  and  Validation  Results; 

1.  Specifications  Reviewed  and  Validated 


SPEC  NQ.  PART  NO. 


BQPT . /COMP , 

SOFTWARE  CONFIGURATION 

CATE  NOMENCLATURE  ITEM  NO. 


2.  Specifications  Reviewed  and  Disapproved: 
(Provide  attachment  for  causes.) 
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PHYSICAL  CONFIGURATION  AUDIT 

CERTIFICATION  stfSST  NO.  3 
( Equipment i 

Contract:  _ , Date  _ 

Contractor : 


Drawing  Review.  Drawings  have  been  compared  with  the  equipment  to 
ensure  that  the  latest  drawing  change  letter  has  been  incorporated 
into  the  equipment,  that  part  numbers  agree  with  the  drawings,  and 
that  the  drawings  are  complete  and  accurately  describe  the  equipment. 

Attachment  _  is  a  list  of  the  drawings  reviewed. 

Check  One  ^ 

The  drawings  are  complete  and  accurately  describe  the  equipment. 
U“I  See  attachment _ for  comments. 

□  Attachment  _  is  a  list  of  discrepancies. 

Signature(s)  of  PCA  Team  Members ( s ) 


* 


•Sub-Team  Chairperson 


Figure  4 
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A.  Drawing  Review  Results.  The  following  drawings  were  reviewed 
by  the  PCA  drawing  reviewing  aub-teaws: 


DOCUMENT  NUMBER 


DOCUMENT  TITLE 
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PHYSICAL  CONFIGURATION  AUDIT 

CERTIFICATION  SHEET  NO.  4 
i Equipment ) 


Contract:  Date 


Contractor: 


Acceptance  Test  Procedures  and  Results.  The  acceptance  test  result* 
have  been  reviewed  to  ensure  that  testing  is  adequate,  properly  done, 
and  certified. 


Attachment  _  is  a  list  of  the  documents  reviewed. 

checic  One 

□  Procedures  and  results  reviewed  satisfy  the  requirements 
and  are  accepted.  See  Attachment  _  for  comments. 

Attachment  ___  is  a  list  of  discrepancies. 

Signature (s)  of  PCA  Team  Member (s) 

* 


•Sub-Team  Chairperson 


Figure  4 
Page  10  of  20 


106 


MIL-STD-J.521B 
APPENDIX  I 


PHYSICAL  CONFIGURATION  AUDIT 

CERTIFICATION  SHEET  NO.  S 
(For  Equipment/Computer  Software) 


Contract  _ _  Date 

Contractor: 


Review  of  Shortages  and  Unincorporated  Design  Changes.  The  shortages 
and  unincorporated  design  changes  listed  Tan  the  proposed  DD  Form  250 , 
"Material  Inspection  and  Receiving  Report" ,  and  other  records  have 
been  reviewed . 

Check  One 

There  are  no  shortages  or  unincorporated  design  changes. 

Attachment  _  is  a  list  of  shortages  and/or  unincorporated 

design  changes,  and  the  recommended  corrective  action  required. 

Signature ( s )  of  PCA  Team  Member (s) 

* 


* Sub-Team  Chairperson 


Figure  4 
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Review  of  Shortages  and  Unicorporated  Design  Changes. 

All  shortages  ana  unieorparatea  design  changes  listed 
on  the  proposed  DD  Form  250,  "Material  Inspection  and 
Receiving  Report",  shall  he  reviewed  by  the  Contracting 
Agency  or  their  designated  representatives  for  a  deter¬ 
mination  of  what  changes  should  be  accomplished  in  the 
field  and  what  changes  should  be  accomplished  at  the 
contractor's  facility.  The  Contracting  Agency  shall 
also  determine  if  the  reported  shortages  and  unincor¬ 
porated  changes  are  complete. 

Results .  List  the  shortages  and  unincorporated  design 
changes  that  were  reviewed  in  compliance  with  requirements. 


Figure  4 
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PHYSICAL  CONFIGURATION  AOPIT 

CFRTITICATION  SETCT  HQ.  6 
(For  Equipment/Computer  Software) 


Contract :  Date 

Contractor:  _ 


Review  Deviations/Waivers.  A  review  of  ali  deviations/waivers  to 
military  specif icatioris  and  standards  that  have  been  approved. 

The  purpose  is  to  determine  the  extent  tc>  which  the  equipment  ( s )/ 
computer  software  undergoing  PCA  vary  from  applicable  specifica¬ 
tions  and  standards  and  to  form  a  basis  for  satisfactory  compliance 
with  these  specifications  and  standards. 

In  accordance  with  this  paragraph,  all  applicable  deviations/ 
waivers  have  bet.:  reviewed  with  the  following  results: 

Check  One. 

The  equipment ( s )/compu ter  software  listed  on  Certification 
Sheet  No.  1  of  this  report  complies  with  all  applicable 
specifications  and  standards.  See  Attachment  _  for  comments. 

Attachment  ___  is  a  list  of  discrepancies  and/or  comments. 


Signature 


(*)' 


of 


PCA  Team  Member ( s ) 


"■Sub-Team  Chairperson 


10  9 
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A.  Peviation/Waiver  Review  Team  instruction.  All  approved  waivers 
and  deviations  to  military  specifications  ana  standards  snail  be 
reviewed  and  recorded-  Also,  record  any  part  of  the  PCA  which 
fails  to  meet  specifications  or  standards  but  is  not  an  approved 
waiver/deviation. 

B,  Results  of  Team  Review.  List  the  deviations/waivers  against  the 
•quTpment/computer  software  being  PCA’ a  that  were  reviewed.. 


Figure  4 
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PHYSICAL  CONFIGURATION  V.CTT 

csBimcaiiBE.  ?sset 

(For  Equipment  / Cotnpu cer  Software) 
Contract:  _  Date  _ 


Contractor : 


Examination  cf  the  Proposed  DD  250.  The  DD  Form  250  has  been  examine* 
to”ensure  £Sat~Tt  adequately  defines  the  equipment/computer  software 
and  that  unaccomplished  tasks  are  inlcuded  as  deficiencies. 

Check  One 

| — j  The  DD  Form  250  adequately  defines  the  equipment/computer 
^  software  and  all  unaccomplished  tasks  are  included  as 
deficiencies . 

Q  Attachment  —  is  a  list  of  discrepancies  and/or  comments. 

Signature (s)  of  PCA  Team  Member(s) 

* 


*Sub-Team  Chairperson 


Figure  4 
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A.  Exami nation  of  the  Proposed  DP  Form  250.  The  proposed  DD  Form 
25(J"~~shair  be  examined  Tor  completeness  and  an  accurate  definition 
of  the  equipment/computer  software.  Unaccomplished  tasics, 
shortages,  and  certain  specified  discrepancies  uncovered  at  tne 
PCA  shall  be  included  in  the  DD  Form  250.  If  the  equipment/ 
computer  software  is  to  be  shipped  from  the  plant,  the  Program 
Office  representative  will  recommend  to  the  CAO  that  the  DD  Form 
250  be  executed  in  accordance  with  the  terms  of  the  contract. 

B.  Results .  Include  a  statement  that  the  proposed*!®  Fora  250  was 
examined  and  was  recommended. 


Figure  4 
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PHYSICAL  CONFIGURATION  ALT) I? 

CERTIFICATION  SHEET  SO^.B. 
{For  Equipment/Computer  Software) 


Contract: _ _  Date 


Contractor : 


Review  of  Contractor's  Engineering  Release  and  Change  Control  System. 
The  contractor's  engineering  release  system  and  change  control  proce¬ 
dures  have  been  reviewed  to  ensure  that  they  are  adequate  to  properly 
control  the  processing  and  formal  release  of  engineering  changes. 

Check  One 


The  contractors  engineering  release  system  and  change  control 
procedures  are  adequate  for  the  processing  and  formal  release 
of  engineering  changes..  See  Attachment  _  for  comments. 

Attachment  is  a  list  of  deficiencies. 


Signature(s)  of  PCA  Team  Member (s 5 


MIL-STD-1521 S 
APPENDIX  I 


!For  Equipment/ Computer  Software 


Contract : 


Data : 


Contractor : 


System  Allocation  Document  Review.  The  following  System  Allocation 
book,  form  drawings  have  been  reviewed  ar.d  validated  to  ensure  that 
they  adequately  identify,  and  are  compatible  with,  the  shipping 
instructions. 

Check  One 

n  The  System  Allocation  Document  is  complete  and  adequately 
defines  the  equipment/computer  software  scheduled  for  each 
location. 

□  The  System  Allocation  Document  is  unacceptable.  Attached  is 
a  list  of  discrepancies. 

(3  This  task  is  not  required  by  contract. 

Signatures )  of  FCA  Team  Member  is) 


Sub-Team  Chairperson 


Figure  4 
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i 

A.  System  Allocation  Document  Instructions : 

i 

I  1.  The  System  Allocation  Documents,  both  Part  I  and  Part  II, 

I  applicable  to  the  contract  shall  be  reviewed  to  determine  their 

accuracy  and  insure  that  they  adequately  describe  the  equipment/ 
computer  software. 

2.  The  following  information  shall  be  recorded: 

Part  I . 


a. 

b. 

c. 

d. 


e . 


) 


g. 

h. 


System  employment  and  configuration. 
Specification  reference. 

Location . 

Mission  Equipment. 

Configuration  Item  Number 
Short  Title 
Part  Number 
Serial  Number 

Installed  equipment/computer  software. 

Configuration  Item  Number 

Short  Title 

Part  Number 

Serial  Number 

Drawing  Title  and  Number 

Number  of  sheets 

Issue  Number. 


Part  II. 

a.  Location. 

b.  Specification  Number 

c.  Equipment/ccmputer  software  nomenclature. 

d.  Configuration  Item  Quantity. 

e.  Assembly  Drawing  Number 

3.  Insure  that  the  System  Allocation  Documents  are  compatible  w 
che  priorities  and  shipping  instructions. 

3 .  System  Allocation  Document  Review  Results.  'The  following  System 
allocation  Documents  were  reviewed  by  the” PCA  Reviewing  Sub-Team: 


DOCUMENT  NUMBER 


DOCUMENT  TITLE 


Figure  4 
Page  15  of  20 


115 


MIL-STD-1521B 
APPENDIX  I 


PHYSICAL  CONFIGURATION  ATO IT 

CERT I? T CAT ION  SHEET  NO.  10 
( Equipment ) 

Contract: _ Dace  _ _ _ _ _____ 

Contractor:  _ 


i.  Review  of  Logistics  Support  Plan  for  Pre-operationai  Support. 

The  Logistics  Support  Plan- for  Pre-operatAellai*  Support  has  been“ 
raviewed  to  ensure  that  it  is  adequate  tt  support  the  acquisition 
phase  and  is  compatible  with  the  operational  phase  maintenance  concept 
and  support  requirements. 

Check  One 


□  The  contractor's  Logittie  Plan  for  pre-operational  support 
will  fulfill  the  acquisition  phase  requirements  and  is  com¬ 
patible  with  operational  phase  needs. 

0  Attachment  _  is  a  list  of  deficiencies. 

Review  of  Lotm  Lead  Time  Items  and  Provisioned  Items  Processed  to 
PCA .  Lon?  Lend  Time  items  released  and  items  provisioned,  prior  to 
PCA  have  been  reviewed  to  ensure  that  obsolete  items  resulting  from 
pre-PCA  design  changes  are  purged  from  the  system.  Where  basic  items 
may  be  upgraded  by  rework  or  modification  these  actions  have  been 
verified  as  accomplished  or  in  process  based  upon  design  change  notice. 

Check  One 


("*]  Long  lead  time  items  and  provisioned  items  processed,  prior  to  PCA, 
are  all  of  current  configuration  at  time  of  PCA  or  are  in  work. 

n  Attachment  _  is  a  list  of  deficiencies. 

Signature ( s )  cf  PCA  Team  Member (s) 


*Sub-Team  Chairperson 
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100.  Appli cat  ion. Guide  for  Tailoring  MIL-STD-1521 

100.1  Scope 

This  appendix  sets  forth  guidance  for  the  cost  effective 
application  of  the  requirements  of  this  standard  when  this 
standard  is  contractually  invoked  during  the  acquisition  process. 
This  appendix  serves  as  guidance  for  the  activity  responsible  for 
the  preparation  of  contract  requirements  and  does  not  fora  a  part 
of  the  contract. 

100.2  Purpose 

The  guidelines  contained  herein  implement  the  Department  of 
Defense  Directive  4120.21,  Specification  and  Standards 
Application,  which  requires  all  DOD  components  to  apply 
selectively  and  tailor  military  spec i f i cat  ions  and  standards  prior 
to  their  contractual  imposition  and: 

a.  Eliminate  inapplicable  and  unnecessary  requirements. 

b.  Provide  for  adding/modifying  necessary  technical  review  and 
audit  factors  not  included  in  MIL-STD-1S21 . 

c.  Eliminate  redundancy  and  inconsistency  with  other  contract 
specifications  and  standards. 

100.3  Objective 

The  objective  of  this  guide  is  to  establish  the  applications  and 
limitations  of  tailoring  MIL-STD-1521.  MIL-STD-1521  is  not  a 
stand-alone  document.  It  is  dependent  upon  the  work  effort 
specified  in  the  contractual  requirements  (e.g.,  SOW,  etc.)  The 
tailoring  of  specifications  should  take  place  in  all  phases  of 
military  procurement,  but  is  especially  applicable  to  the  initial 
stages  of  solicitation  package  preparation  and  contract 
negotiation.  Depending  upon  the  type  of  end-item(s)  under 
procurement,  the  reviews  and  audits  outlined  by  MIL-STD-1521  may 
or  may  not  be  required  for  all  programs. 

100.4  Considerat ions  for  Tailoring 

100.4.1  Relationship  to  the  Statement  of  work 

The  Program  Manager  must  keep  in  mind  that  technical  reviews 
provide  visibility  into  the  contractor's  implementation  of  the 
work  effort  required  under  the  terms  of  the  SOW  and  the  contract 
to  assure  timely  and  effective  attention  to  the  technical 
interpretation  of  contract  requirements.  The  key  to  tailoring 
MIL-STD-1521  is  to  match  the  MIL-STD-1521  requirements  against  the 
details  of  the  applicable  SOW/Contractual  task  requirements.  It 
will  become  immediately  obvious  that  MIL-STD-1521  may  contain 
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technical  review  factors  that  are  not  applicable  to  the  contract 
under  consideration.  (For  example,  if  a  contract  does  not  include 
computer  software,  all  references  to  the  review  of  Computer 
Software  materials  in  MIL-STD-1521  will  not  apply.)  when 
MIL-STD-1521  is  used,  then  a  task  containing  the  applicable 
requirements  will  be  specified  in  the  SOW.  Review  factors  not  set 
forth  in  MIL-STD-1521  but  considered  necessary  because  of  the 
nature  of  the  particular  program  should  be  added  in  the  SOW.  9y 
carefully  going  through  this  evaluative  process  the  technical 
review  and  audit  requirements  will  become  program  specific  rather 
than  an  all  purpose  document  to  be  continually  negotiated  during 
contract  performance. 

100.4.2  El xminat ion  of  Redundancy  and  Ambiguity 

While  MIL-STD-1521  is  the  broad  program  document  for  technical 
reviews  and  audits,  other  standards  in  existence  also  require 
technical  reviews  or  audits.  For  example,  MIL-STDs  for 
reliability,  ma inta inab i 1 i ty ,  system  engineering  and  others  can 
require  reviews  and/or  audits.  Review  of  these  aspects  of  the 
design  would  also  be  required  under  MIL-STD-1521;  therefore,  if 
such  standards  are  contractually  stipulated  together  with 
MIL-STD-1521,  the  SOW  should  include  a  provision  to  show  how  and 
whether  the  technical  review  requirements  of  these  other  standards 
can  be  combined  with  technical  revi ews/audi ts  in  MIL-STD-1521 
Combining  reviews  does  not.  nullify  other  MIL-STD(s),  "Plans",  etc, 
which  contain  requirements  for  reviews/audits.  The  contract 
should  require  the  minimal  integrated,  comprehensive  technical 
design  review  effort  that  will  provide  the  desired  visibility  and 
assurance  of  contract  compliance. 

,100.4.3  Contractor  Part  i  c  ipat  ion  i  n  Tailoring 

When  requiring  a  particular  review  or  audit,  it  is  important  that 
the  topics  to  be  reviewed  are  aligned  to  the  program  requirements. 
Therefore,  the  offeror  should  be  given  an  opportunity  to  recommend 
changes  and  identify  topics/items  he  considers  'appropriate.  The 
program  office  should  request,  in  the  instructions  for  proposal 
preparation,  that  the  offeror  recommend  the  MIL-STD-1521 
topics/items  and  their  related  details  to  be  covered  at  the 
various  reviews  or  audits  required  by  the  SOW.  This  will  allow 
the  offeror  to  tailor  the  topics/items  and  details  by  additions 
and  deletions  for  the  particular  review/audit.  In  addition,  it 
must  be  recognized  that  effecive  tailoring  requires  several  points 
of  review.  The  requirement,  however,  for  the  reviev/audit  must  be 
finalized  prior  to  contract  award. 

100  .-4. 4  Complexity 

a.  System/Segment/subsystem/conf igurat ion  item  complexity  and 
type  of  program  is  central  in  determining  both  the  need  for 
and  the  number  of  such  reviews.  when  developing  s  small 
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non-corap lex  system  some  reviews  raay  not  be  required,  or,  if 
required,  raay  bo  limited  in  Scope.  The  tailoring  procedures 
discussed  earlier  should  result  either  in  the  exclusion  cf 
MIL-STD- 1521  or  in  a  tailored  MIL-S7D-1521  that  reflects  a 
limited  scope  technical  review  effort.  Conversely,  in  a 
very  complex  development  the  review  process  vill  increase  in 
levels  and  numbers  of  review*. 

b.  In  addition  to  the  above,  the  degree  of  application  is 
dependent  upon  the  configuration  item  state  of  development 
(example,  new  design  vs.  commercially  available)  or  the 
degree  of  rny  modi  f  icat  ions .  if  involved.  For  example:  a 
newly  developed  item  may  require  the  majority  of  the  review 
topics/items  and  audits,  while  a  commercially  available 
configuration  item  with  the  appropriate  documentation,  i.e., 
verified  test  results,  specifications,  drawings,  etc.  may 
require  reviews  or  audits  limited  to  its  application  to  the 
program  and  its  interfaces.  In  the  case  of  modified  designs 
one  must  consider  the  degree  and  effect  of  the 

modifications.  Reviews  and  audits  may  be  limited  to  the 
modifications  and  their  interfaces. 

100.5  Schedul  ina  of  Technical  Reviews  and  Aud  i  t's 

The  schedule  for  Technical  Reviews  and  Audits  is  extremely 
important.  If  they  are  conducted  too  early,  the  item  for  review 
will  not  be  adequately  defined.  Conversely,  if  the  review  i®  too 
late,  the  program  commitments  could  have  been  made  erroneously, 
and  correction  will  be  both  difficult  and  costly.  For  planning 
purposes.  a  good  method  for  scheduling  technical  reviews  is  to 
relate  them  to  the  documentation  requirements.  For  example, 
schedule  a  PDR  after  the  hardware  Development  Specification  or 
Software  Top  Level  Design  Document  and  Software  Test  Plan  are 
available,  since  the  essence  of  the  PDR  is  to  assess  the 
contractor's  approach  to  meeting  these  requirements  of  these 
documents.  Scheduling  of  audits  are  dependent  not  only  or. 
documentation  availability  but  also  on  hardware/software 
availability,  and  the  completion  of  the  acceptance  qualification 
tests.  Table  1  contains  a  list  of  the  primary  documentation 
associated  with  each  review  or  audit  and  the  estimated  time 
phas ing : 


TABLE  1 

SCHEDULING  TECHNICAL  REVIEWS  AND  AUDITS 


Review  Time  Phase 


Pr imary  Documentat ion 


SRR 


Usually  accomplished  in  the 
Concept  Exploration  phase. 
However,  raay  be  used  in 
other  phases  when  the 


Various  analysis  and 
trade  study  reports 
used  to  develop  the 
system/segment 
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Review 


SDR 


SSR 


FDR 


CDR 


Time  Phase 


Primary  Documentation 


Concept  Exploration  phase  requirements  for  the 

is  not  accomplished.  specification. 


Usually  in  the  Demonstration 
and  Validation  phase. 


S ystem/Segment 
Specif icat ion , 
preliminary  Operational 
Concept  Document, 
preliminary  Software 
Requirements  and 
Interface  Requirements 
Specifications,  analyses, 
trade  studies.  Drawings 
Level  I  DOD-D-1 000 . 


Usually  early  in  Full 
Scale  Development 


Software  Requirements 
Specification,  Interface 
Requirements 
Spec i * icat ions , 
Operational  Concept 
Document . 


Usually  accomplished  in  the 

Demonstration  and  validation 
and/or  Full  Scale 
Development  Phase 


Development,  Type  E 
Performance 
Specification, 

Drawings  Level  I 
DOD-D-IOOO,  Software 
Top  Level  Design 
Document,  Software  Test 
Plan,  preliminary 
Computer  Resources 
Integrated  Support 
Document,  preliminary 
Computer  System 
Operator’s  Manual, 
preliminary  Software 
User’s  Manual , 
preliminary  Computer 
System  Diagnostic  Manual. 


m 


Usually  accomplished  in  the 
Full  Scale  Development 
phase 


Draft  Product,  Type  C 
Spc-c  if  icat  ion ,  and 
referenced  documentation, 
Drawings  Level  I  or  i 1 
DOD-D-- 1000,  Software 
Detailed  Design  Document, 
Interface  Design 
Document (s).  Data  East- 
Design  Document ( s > , 
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Review 


Tine  Phase 


Pr imarv  Documentation 


Software  Test 
Description,  Computer 
Resources  Integrated 
Support  Document, 
Software  Programmer ' s 
Manual,  Firmware 
Support  Manuel,  Informal 
Test  Descriptions/Test 
Procedures,  Software 
Development  File(s), 


TRR  Usually  accomplished  in 

the  Full  Scale  Development 
phase 


Software  Test  Procedure, 
Informal  software  test 
results  (of  development 
tests )  . 


FCA  Usually  accomplished  at 

end  of  Full  Scale 
Development 


PCA  Usually  accomplished  early 

in  the  initial  production 
when  the  developing 
contractor  is  preselected 
as  the  production 
contractor.  However,  may 
be  accomplished  at  the  end 
of  Full  Scale  Development 
when  the  developing 
contractor  is  not 
preselected  as  the 
production  contractor. 

And  the  PCA  is  repeated 
with  e^ch  subsequent 
contractor  or  break 
in  production. 


Test  plans,  test 
descriptions,  test 
procedures.  Software 
Test  Reports,  Computer 
System  Operator’s  Manual, 
Software  User’s  Manual 
Computer  System 
Diagnostic  Manual. 

Final  Part.  II 
Specification/Type  C 
Product  Specifications 
and  referenced  documents 
and  drawings.  Drawings 
Level  II  or  III 
DOD-D-IOOO.  Software 
Product  Specification, 
Version  Description 
Document . 


Although  the  time  frame  for  reviews  and  audits  is  suggested  above, 
they  may  very  depending  on  the  particular  program.  The  schedule 
for  each  review  or  audit  may  be  requested  from  the  offeror  as  part 
of  his  proposal,  or  as  part  of  the  system  engineering  management 
plan  (which  can  be  part  of  the  proposal). 
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110.  Product  ion  Readiness  Review  ( PRR ) 

110.  i  For  specific  guidance,  see  AFSCR  64-2,  Production  Readiness 
Review. 
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3*10  Production  Readiness  Review  (PER).,  This  review  1b  intended  to  determine 
the  stetUB  of  completion  of  the  specific  actions  which  must  be  satisfactorily 
accomplished  prior  to  executing  a  production  go-ahead  decision.  The  review  is 
accomplished  in  an  incremental  fashion  during  the  Full-Scale  Development 
phase,  usually  two  initial  reviews  and  one  final  review  to  asseaa  the  risk  in 
exercising  the  production  go-ahead  decision,  in  its  earlier  stages  the  FSfi 
concerns  itself  with  gross  level  aanafsetnring  concerns  such  ss  the  need  for 
identifying  high  r Ask/low  yield  manufacturing  processes  or  materials  or  the 
requirement  for  manufacturing  development  effort  to  satisfy  design 
requirements.  The  reviews  became  sore  refined  as  the  design  matures,  dealing 
with  sneh  concerns  ss  production  planning,  facilities  allocation, 
incorporation  of  producibillty-oriented  changes,  identification  and 
fabrication  of  tools/test  equipment,  long  lead  item  acquisition  etc.  Timing 
of  the  incremental  FRRs  is  a  function  of  program  posture  and  is  not 
specifically  locked  in  to  other  reviews. 

OTHER  bfcFIHITIOSS 

3.11  For  further  guidance  on  cost  terminology  see  the  latest  edition  of  DODI 
5000.32,  Uniform  budget/cost  Terms  and  Definitions. 

3.12  Mew  titles  are  being  phased  in  for  the  levels  of  maintenance.  They  are 

(with  their  former  terms):  On  Equipment  (Organizational),  Off  Equipment  -  On 
Site  (Intermediate),  Off  Equipment  -  Off  Site  (Depot).  See  the  latest  edition 
of  SFR  Equipment  Maintenance  Policies,  Objectives,  end  Reponeibiiities. 

3.13  For  dtf initiciis  of  the  various  levels  of  repair,  see  the  latest  edition 
of  Mllr— STD-28UA,  Definition  of  Item  Levels,  Iter.  Exchangeability,  Models,  and 
Related  Terms. 

3.14  Configuration  item.  Hardware  or  software,  or  at.  aggregation  of  both, 
which  is  designated  by  the  contracting  agency  for  configuration  management. 

3.15  Engineering  Data:  Engineering  documents  such  as  drawings,  associated 
lists,  accompanying  documents,  manufacturer  specifications,  manufacturing 
planning  documentation,  and  standards  or  other  information  prepared  by  a 
design  activity  and  relating  to  the  design,  manufacture,  procurement,  test,  or 
Inspection  of  hardware  items  or  services,  as  defined  in  DOb-STD-lOO  and 
DOD-D-1DOO. 
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10.  System  Requirements  Review  (SSR). 

10.1  General.  The  SRRa  are  no  really  conducted  during  the  systsm  concept 
Exploration  or  Demoastrntios  and  Validation  pbaae.  Such  review  may  be 
conduct  **2  at  any  tine  but  nornally  will  be  conducted  after  the  accompli rtwcmt 
of  functional  analysis  and  prelininary  requirement*  allocation  (to 
operatlonal/Miotenance/training  Bard  ware  configuration  I  ten*  (flWCXs), 

Conputer  Software  configuration  Itenc  (cncia),  facility  configuration  item, 
manufacturing  considerations,  personnel  and  bunas  factors)  to  determine 
initial  direction  and  progress  of  the  contractor's  Systen  Engineering 
Management  effort  and  hie  convergence  upon  an  optinun  and  complete 
configuration. 

10.2  Purpose.  She  total  System  Engineering  Management  activity  and  its 
output  shall  be  reviewed  for  responsiveness  to  the  Statement  of  Work  and 
•ysten/segment  requirements.  Contracting  agency  direction  to  the  contractor 
will  be  provided,  as  necessary,  for  continuing  the  technical  program  and 
system  optimization. 

10.3  Items  to  be  Reviewed.  Representative  items  to  be  reviewed  include  the 
results  of  the  following,  as  appropriate: 

a.  Mission  and  Requirements  Analysis 

b.  Functional  Plow  Analysis 

c.  Preliminary  Requirements  Allocation 

d.  System/ Cost  Effectiveness  Analysis 

e.  Trade  studies  (e.g,  addressing  system  functions  in  mission  and 
support  hardware/f Armware/software) . 

f.  Synthesis 

g.  Logistics  Support  Analysis 

h.  specialty  discipline  Studies  (i.e..  hardware  and  software  reliability 
analysis,  maintainability  analysis,  armament  integration,  electromagnetic 
compatibility,  survivability/vulnerability  (including  nuclear),  inspection 
methods/techniques  analysis,  energy  management,  environmental  considerations) . 

i.  system  Interface  Studies 

j.  Generation  of  Specification 

k.  Program  Risk  Analysis 

l.  Integrated  Test  Planning 
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a.  producibility  Analysis  Plans 
a.  Technical  performance  Measurement  Planning 

o.  engineering  integration 

p.  Data  Management  Plana 

g.  Configuration  Management  Plans 
r.  System  safety 
a.  Hunan  Factors  Analysis 
t«  Value  Kngicx  ;ring  Studies 

u.  Life  Cycle  Coat  Analysis 

v.  Preliiainary  Manufacturing  Plans 

w.  Manpower  Requirements/ personnel  Analysis 

x.  Milestone  Schedules 

10.3.1  The  contractor  shall  deacribe  his  progress  end  problems  in: 

10.3.1.1  Kisk  identification  and  riek  ranking  (the  interrelationship  among 
systen  effectiveness  analysis,  technical  performance  measurement,  intended 
manufacturing  methods,  and  costs  shall  be  discussed,  as  appropriate), 

10.3.1  2  Risk  avoidanee/reduction  and  control  (the  interrelationships  with 
trade-off  studies,  test  planning,  hardware  proofing,  and  technical  performance 
measurement  shall  be  discussed,  as  appropriate). 

10.3.1.3  Significant  trade-effs  among  stated  systea/aegment  specification 
requirements/ constraints  and  resulting  engineering  design  requirements/ 
constraints,  manufacturing  metbods/pre^ess  constraints,  and  logictic/cost  of 
ownership  regnir«uxnts/conatraintc  and  unit  production  eoct/design-to-coct 
objectives . 

10.3.1.4  Identifying  computer  resources  of  the  system  and  partitioning  the 
system  into  SWCis  and  cscis.  include  any  trade-off  studies  conducted  to 
evaluate  alternative  approaches  and  methods  for  meeting  operational  needs  and 
to  determine  the  effects  of  constraints  on  the  system.  Also  include  any 
evaluations  of  logistics,  technology,  cost,  schedule,  resource  limitations, 
intelligence  estimates,  etc..,  autde  to  determine  their  Impact  on  the  system. 

In  addition,  address  the  following  specific  trade-offs  related  to  coisp-'ter 
resources : 
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£ .  Survivability/Vulnerability  (including  nizcloet) 
j.  Reli abil  i ty /Main t alcabl 1 i ty/Ava liability  (R/M/A) 

h.  Electromagnetic  Compatibility 

i.  Logistic  Support  Analysis  to  address,  as  appropriate,  integrated 
logistics  support  including  maintenance  concept,  support  equipment  concept, 
logistics  support  concept,  maintenance,  supply,  software  support  facilities, 
etc.  (KIL-STD- 1388-1  and  2) 

j .  system  Safety  (emphasis  shall  be  placed  on  system  hasard  analysia  and 
identification  of  safety  teat  requirements) 

k.  Security 

1<.  Human  factors 

m.  Transportability  (Including  Packaging  and  Sandllng) 

n.  System  Hass  Properties 

o.  Standardization 

p.  Electronic  Warfare 
O .  Value  Engineering 

r.  System  Growth  capability 

s.  Program  Risk  analysis 

t.  Technical  performance  Measurement  Planning 

u.  producibility  Analysis  and  Manufacturing 

v.  Life  Cycle  Cost/Design  to  cost  Goals 
v.  Quality  Assurance  Program 

x.  Environmental  Conditions  (Temperature,  Vibration,  Shock,  Humidity, 

etc) . 

y.  Training  and  Training  Support 
i.  Milestone  Schedules 

aa.  software  Development  Procedures 
20.3.2  Results  of  significant  trade  studies,  for  example: 

a.  Sensitivity  of  selected  mission  requirements  versus 
Supersedes  page  25  of  4  dune  1985 
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realistic  performance  p«ramt«ri  and  cost  estimates. 

to.  Operations  design  versa*  maintenance  design,  including  support 
equipment  impacts. 

c.  System  centralization  versus  decentralization 

d.  Automated  versos  manual  operation 

e.  Reliability  /Malntainobility /Availability 

t.  Coemerclally  available  iteas  versus  new  developments 

g.  Rational  Stock  Muatoer  (MSN)  iteaa  versus  new  development 

b.  Testability  trade  studies  (Allocation  of  fault  detection/isolation 
capabilities  between  elements  of  built-in  test,  on  board/oit-site  fault 
detection/isolation  subsystem,  separate  support  equipment,  and  manual 
procedures) 

i.  Size  and  weight 

j.  Desired  propagation  characteristics  versus  reduction  interference  to 
other  systems  (optimum  selection  frequencies) 

k.  Performance/logistics  trade  studies 

l.  Life  cycle  cost  reduction  for  different  computer  programming  languages 

s.  Functional  allocation  between  hardware,  software,  firmware  and 
personnel/procedures 

n.  Life  Cycle  cost/system  performance  trade  studies  to  include 
sensitivity  of  performance  parameters  to  cost. 

o.  Sensitivity  of  performance  parameters  versus  cost 

p.  Cost  versus  perforatance 

q.  Design  versus  manufacturing  consideration 

r.  Hake  versus  buy 

s*  Software  development  schedule 

t.  On-equipment  versus  of  f-egr.ipment  maintenance  tasks,  including 
support  equipment  impacts 

u.  common  versus  peculiar  support  equipment 

20.3.3  Opdated  design  requirements  for  operations/maintenance  functions  and 
items. 

20.3.4  Updated  requirements  for  manufacturing  method*  and  processes. 
Supersedes  page  26  of  4  June  1985 
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1.  Maintenance  related  trade-off  studios  end  findings  (includes 
ircially  available  equipment,  software  fault  diagnostic  tschuiqnas) 


j.  Logistic  cost  ispset s 


k.  Support  procedures  and  tool*  for  computer  software  which  facilitate 
software  aodiflcation,  improvements,  corrections  and  updates 

l.  Hardness  critical  itesa/procesaes 
s.  Support  squipment  concept* 


20.3,12  System  conpliance  with  nuclear,  non-nuclear  and  laser  hardening 
requi resents  *  High  risk  arees  or  design  concepts  requiring  possible  advances 
of  the  state-of-the-art  as  a  result  of  survivability  criteria  shall  be 
identified,  and  prepared  approacb(es)  to  the  problcs  reviewed*  Prepared  test 
progress  shell  be  reviewed  for  sufficiency  and  compatibility  with  the 
specified  threat  environment  and  existing  simulation  test  facilities. 


20.3.13  The  optimization,  traceability,  completeness,  and  risks  associated 
with  the  allocation  technical  requirements,  and  the  adequacy  of  allocated 
system  requirements  as  a  basis  for  proceeding  with  the  development  of  hardware 
and  software  configuration  items .  include  any  available  preliminary  Software 
Requirements  and  interface  Requirements  Specifications. 


20.3.14 


Manufacturing  (HWCls  only). 


20.3.14.1  Production  feasibility  and  risk  analyses  addressed  at  the  6RR  shall 
be  updated  and  expanded.  This  effort  should  review  the  progress  made  in 
reducing  production  risk  and  evaluate  the  risk  remaining  for  consideration  in 
the  Full  Scale  Development  Phase.  Estimates  of  cost  and  schedule  impacts 
shall  be  updated. 


20.3.14.2  Review  of  the  production  Capability  Assessment  shall  include: 


20.3.14.2.1  A  review  of  production  capability  shall  be  accomplished  which 
will  constitute  an  assessment  of  the  facilities,  materials,  methods, 
processes,  equipment  and  skills  necessary  to  perform  the  full  scale 
development  and  production  efforts,  identification  of  requirements  to  upgrade 
or  develop  manufacturing  capabilities  shall  be  made.  Requirements  for 
Manufacturing  Technology  (HANTECB)  programs  will  also  be  identified  as  an 
element  of  this  production  assessment. 

20.3.14.3  Present  the  management  controls  and  the  design/manufacturing 
engineering  approach  to  assure  that  the  equipment  is  producible. 
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20.3*14.4  prevent  e  review  of  trade-off  studies  for  design  requirement* 
«g«in*t  the  requirement  for  producibility ,  facilities,  tooling,  production 
teat  equipment,  inspection,  and  capital  equipment  foe  intended  production 
rates  end  volume. 

20.3.14.5  The  analysis,  Assessments  and  trade-off  studies  should  recommend 
any  additional  special  studies  or  development  efforts  as  needed. 

20.3.15.  Engineering  Data.  Evaluate  the  contractor**  drawing  system, 
reviewing  the  drafting  room  manual,  the  preparation  and  review  procedures, 
change  control  procedures,  fiowdown  of  requirements  to  subcontractors  slid 
vendors,  and  other  aspects  fundamental  to  the  acceptability  of  Level  3 
drawings.  If  available,  review  completed  drawings  from  other  programs  or  the 
normal  company  product  line  to  determine  compliance  with  the  company 
procedural. 

20. 4  Post  Review  Action.  After  completing  the  SBR,  the  contractor  shall 
publish  and  distribute  copies  of  Review  hinutes.  The  contracting  agency 
officially  acknowledges  completion  of  the  SDR  as  indicated  in  paragraph  4.2.4. 
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nt  shall  be  made  available  for  review  by  the  contracting  agency. 


*»  firmware  to  be  provided  with  the  system;  microprogram  logic  tifm grama 
r«d  reprogramming/ instruction  translation  algorithm  descriptions,  fabrication, 
aekaging  (integration  technology  <e.g.,  LSI,  RSI),  device  typas  (e.g.r  CMOS, 
HO Si),  and  special  equipment  and  support  software  needed  for  developing, 
esting,  and  supporting  the  firmware. 


aa.  Life  Cycle  Cost  Analysis 

ab.  Armament  compatibility 

ac.  Corrosion  prevention/control  considerations 

ad.  Findlnga/Status  of  Quality  Assurance  Program 
*t .  Support  equipment  requirements. 


0.2.2  CSC  Is 


a.  Functional  flow.  The  computer  software  functional  flow  embodying  all 
£  the  requirements  allocated  from  the  Software  Requirements  Specification  and 
nterface  Requirements  Specif ication(  s }  to  the  individual  Top-Level  CoefMiter 
oftware  components  (tlcscs)  of  the  CSCI. 

th.  Storage  allocation  data.  This  information  shall  be  presented  for 
CSCI  as  a  whole,  describing  the  manner  in  which  available  storage  Is 
llocated  to  individual  TLCSCs.  Timing,  sequencing  requirements,  and  relevant 
quipment  constraints  used  in  determining  the  allocation  are  to  be  included. 

c.  Control  functions  description.  A  description  of  the  executive 
ontrol  and  start/recovery  features  for  the  CSCI  shall  be  available,  including 
ethod  of  initiating  system  operation  and  features  enabling  recovery  from 
ystem  malfunction. 

d.  CSCI  structure*  The  contractor  shall  describe  the  top-level 
tructure  of  the  CSCI,  the  ressons  for  choosing  the  components  described,  the 
evelopment  methodology  which  will  be  used  within  the  constraints  of  the 
vailable  computer  resources,  and  any  support  programs  which  will  be  required 
n  order  to  develop/maintain  the  CSCI  structure  and  allocation  of  data  storage. 

e.  Security.  An  identification  of  unique  security  requirements  and  a 
escription  of  the  techniques  to  be  used  for  implementing  and  maintaining 
ecurity  within  the  CSCI  shall  be  provided. 
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f.  ftaentraacv.  An  identification  of  any  reant r an cy  requirement*  and  a 
description  of  the  technique*  for  implementing  reentrant  roun tines  aball  be 
available* 

9*  computer  software  development  facilities.  The  availability# 
adequacy#  and  planned  utilisation  of  tbe  coaputer  software  development 
facilities  shall  be  addressed. 

b.  Coaputer  software  development  facility  versus  the  operational 
ayatea.  The  contractor  shall  provide  information  relative  to  unique  design 
features  which  may  exist  in  a  TLCSC  in  order  to  allow  use  within  the  coaputer 
software  development  facility,  but  which  will  not  exist  in  tbe  TLC6C  installed 
in  the  operational  system.  The  contractor  shall  provide  information  on  the 
design  of  support  programs  not  explicitly  required  for  the  operational  system 
bat  which  will  be  generated  to  assist  in  the  development  of  the  CSCI(s).  The 
contractor  shall  also  provide  details  of  the  software  Development  Library 
controls. 

i.  Development  tools.  The  contractor  shall  describe  any  special 
ainulation,  data  reduction#  or  utility  tools  that  are  not  deliverable  under 
the  terms  of  the  contract,  but  which  are  planned  for  use  during  software 
development. 

j.  Test  tools.  The  contractor  shall  describe  any  special  test  systems, 
teat  data,  data  reduction  tools#  test  computer  software,  or  calibration  and 
diagnostic  software  that  are  not  deliverable  under  terms  of  the  contract,  but 
which  are  planned  for  use  during  product  development. 

k.  Description  and  characteristics  of  commercially  available  computer 
resources,  including  any  optional  capabilities  such  as  special  features, 
interface  units,  special  instructions,  controls,  formats,  etc.  Include 
limitations  of  commercially  available  equipment  such  as  failure  to  meet  human 
engineering,  safety  and  maintainability  requirements  of  the  specification  and 
identify  deficiencies. 

l.  Existing  documentation  (technical  orders,  commercial  manuals#  stc. ) 
for  commercially  available  computer  resources  and  copies  of  contractor 
specifications  used  to  procure  computer  resources  sball  be  made  available  for 
review  by  tbe  contracting  agency. 

a.  support  resources.  The  contractor  shall  describe  those  resources 
necessary  to  support  the  software  and  firmware  during  operational  deployment 
of  tbe  system,  such  as  operational  and  support  hardware  and  software, 
personnel,  special  skills,  human  factors,  configuration  management,  test,  and 
facilities/space . 
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n.  Operation  and  support  documents.  The  preliminary  versions  of  the 
CSOM,  SOM/  CSM,  and  CRISD  shall  be  reviewed  for  technical  content  and 
comparability  with  the  top-level  design  documentation. 

o.  updated  since  the  last  review  to  all  previously  delivered  software 
related  CB&L  item*. 

p.  review  considerations  applicable  to  40.2.1  as  appropriate. 

40.2.3  Support  Equipment  (SB} : 

a.  Review  considerations  applicable  to  paragraph  40.2.1  and  40.2.2  as 
appropriate. 

b.  Verify  testability  analysis  results.  For  example.  on  repairable 
integrated  circuit  boards  are  teat  points  available  so  that  failure  can  be 
isolated  to  the  lowest  level  of  repair  (See  Section  3  Definitions/  for  *bev«l 
of  repair*). 

c.  Verify  that  the  Government  furnished  SE  is  planned  to  be  used  to  tbe 
maximun  extant  possible. 

d.  Review  progress  of  long-lead  tise  SE  item*,  identified  through 
interim  release  and  SE  Requirements  Document  (SERE)  procedures*. 

e.  Review  progress  toward  determining  total  SE  requirements  for 
installation,  checkout,  and  test  support  requirements. 

f.  Review  the  reliability /maint.inability/availability  of  support 
equipment  items. 

g.  Identify  logistic  support  requirements  for  support  equipment  items 
and  rationale  for  their  selection. 

h.  Review  calibration  requirements, 

1.  Describe  technical  manuals  and  data  availability  for  support 
equipment. 

j.  Verify  compatibility  of  proposed  support  equipment  with  the  system 
maintenance  concept. 

k.  If  a  Logistic  Support  Analysis  (LSA)  is  not  done,  then  review  the 
results  of  SE  trade-off  studies  for  each  alternative  support  concept,  rot 
existing  SE  and  printed  circuit  boards  testers,  review  Faintainabilitv  data 
resulting  from  the  field  use  of  these  equipments.  Revxew  the  cost  difference 
between  systems  using  single  or  multipurpose  SE  vs.  proposed  new  SE.  Examine 
technical  feasibility  in 
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osing  existing,  developmental,  and  proposed  new  SE.  For  sob. 11*  systems, 
review  tbs  Mobility  requirement*  of  aupport  equipment. 

1*  Review  the  relationship  of  the  computer  resource*  in  the 
systea/sobsystex  with  those  in  Autoxatic  Test  Equipment  (ATE).  Relate  this  to 
the  develcpemnt  of  Built  In  Test  Equipment  (BITE)  and  try  to  reduce  the  need 
lor  complex  supporting  SE. 

a.  Verify  on-equipment  versus  off-equipment  Maintenance  task  trade  study 
results,  including  support  equipment  impacts. 

c*  Review  updated  list  of  required  support  equipment. 

40.2.4  Engineering  pat*.  Review  Level  1  engineering  drawings  for  ease  of 
conversion  to  higher  levels  and,  if  available,  review  Level  2  and  3  drawings 
for  compliance  with  requirements.  The  review  of  engineering  data,  as  defined 
in  paragraph  3.15,  should  consider  the  checklist  items  discussed  in  para 
100.6,  as  properly  tailored. 

40.3  Evaluation  of  Electrical,  Mechanical,  and  Logical  Designs 

40*3.1  BWCis.  The  material  of  paragraph  40.2.1  above  shall  be  evaluated  to: 

a.  Determine  that  the  preliminary  detail  design  provides  the  capability 
or  satisfying  the  performance  characteristics  paragraph  of  the  BWCI 
Development  specif icaticns. 

b.  Estalbiah  compatibility  of  the  BWCI  operating  characteristics  in  each 
irou*  with  overall  system  design  requirements  if  the  BWCI  is  involved  in 
multi-mode  functions. 

c.  Establish  the  existence  and  nature  of  physical  and  functional 
interfaces  between  the  BWCI  and  other  items  of  equipment,  computer  software, 
and  facilities. 

40.3.2  CSCIe.  The  material  of  paragraph  40.2.2  above  shall  be  evaluated  to: 

a.  Determine  whether  all  interface®  between  the  CSCI  and  all  other 
configuration  items  both  Internal  and  external  to  the  system  meet  the 
requirements  of  the  Software  Requirements  Specification  and  Interface 
Requirements  Specif ication(s) . 

b.  Determine  whether  the  top-level  design  embodies  all  the  requirerjents 
of  the  Software  Requirements  Specification  and  interface  Requirements 
Specification s) . 
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c.  Determine  whether  the  approved  dealer.  methodology  baa  bean  need  for 
t be  top-level  design. 

d.  Deteralr*  whether  the  appropriate  Busan  rector*  Bngineering  (art) 
principal*  have  been  incorporated  in  the  design. 

e.  Determine  whether  timing  end  a icing  constraint*  have  been  met 
throughout  the  top-level  design. 

f.  Deteraine  whether  logic  affecting  eastern  end  nuclear  safety  baa  been 
incorporated  in  the  design. 


ML-MD-ISUB 
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{11}  Survivsbility/Vulnerability  ( including  nuclear) 

(12)  Producibility  end  Manufacturing 

(13)  Transportability,  Packaging  and  handling 

(14)  Buaan  engineering  and  Biomedical  ftequirwents  (including  Lift 
support  and  Crew  Station  JtequireaMnfcs) 

(15)  Standardisation 

(1C)  Design  versus  Logistics  Tr*de~off* 

(17)  Support  equipment  requirements 

d.  Interface  control  drawings 

e«  Nock-up*,  breadboards,  and/or  prototype  hardware 

f.  Design  analysis  snd  test  data 

g.  fiysten  Allocation  Document  for  HHCI  inclusion  st  each  scheduled 
location. 

h.  Initial  Ksnsfacwrisg  Readiness  (for  esasjile,  manufacturing 
engineering,  tooling  demonstrations,  development  and  proofing  of  new 
materials,  processes,  aethods,  tooling,  test  equipment,  procedures,  reduction 
of  manufacturing  riaka  to  acceptable  levels). 

i.  Preliminary  vecps  and/or  forma]  VECPs 

j.  Life  cycle  coats 

k.  Detail  design  information  on  all  firmware  to  be  provided  with  the 

system 

l.  Verify  corrosion  prevent ion/coutrol  considerations  to  insure 
materials  have  been  chosen  that  will  be  compatible  with  operating  environment. 

a.  rindings/StatuE  of  Quality  Assurance  Program 
50.2.3  CSCls. 

a.  Software  Detailed  Design,  Data  Base  Design,  and  interface  Di-sign 
Document (a),  in  cases  where  the  CDR  is  conducted  in  increments,  complete 
documents  to  support  that  increment  shall  be  available. 

b.  supporting  documentation  describing  results  of  analyses,  testing, 
etc,  as  mutually  agreed  by  the  contracting  agency  and  the  contractor. 


Supersede*  page  55  of  4  June  1985 


«XJr-8TD—X521B 
APPEHDIX  B 
19  Dec  85 

c.  System  Allocation  Document  for  C£CX  inclusion  at  each  scheduled 

location. 

d.  cospa ter  Resources  Integrated  support  Document. 

e.  Software  Programmer's  Manual 

f .  Firmware  Support  Manual 

g.  Progress  on  activities  required  by  CSC I  fdb  (para  4G.2.2). 

h.  Updated  operation  and  support  documents  (CSOM,  SOM,  CSDM). 

i.  Schedules  for  remaining  milestones. 

■).  updates  since  the  last  review  to  all  previously  delivered  software 
related  CDRL  items. 

50.2.3  Support  Equipment  (SE); 

a.  Review  requirements  (paragraphs  50.2.1  and  50.2.2)  for  SE. 

b.  Verify  maximum  considerations  GFE  SE 

c.  Identify  existing  or  potential  SE  provisioning  problems 

d.  Determine  qualitative  and  quantitative  adequacy  of  provisioning 
drawings  and  data 

a.  Review  reliability  of  SE 

f.  Review  jogistic  support  requirements  for  SE  items 

g.  Review  Calibration  requirements 

h.  Review  documentation  for  SE. 

50.2.4.  Engineering  Data.  Continuing  from  the  results  of  the  Preliminary 
Design  Review  ( pdr ) ,  review  engineering  data  as  defined  in  para  3.15,  as  to 
suitability  for  intended  use.  The  review  should  consider  the  checklist  items 
discussed  in  para  100.6,  as  properly  tailored. 

50.3  Detailed  Evaluation  of  Electrical,  Mechanical,  and  Logical  Designs 

sn.3.1  HWCIs .  Detailed  block  diagrams,  schematics,  and  logic  diagrams  shall 
be  compared  with  interface  control  drawings  to  determine  system 
compatibility.  Analytical  and  available  test  data  shall  be  reviewed  to  insure 
the  hardware  Development  Specification  has  been  satisfied. 

si 
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50.3.1*1  The  contractor  shall  provide  information  on  firmware  which  is 
included  in  commercially  available  equipment  or  to  be  included  in  equipment 
developed  under  the  contract.  Firmware  in  this  context  includes  the 
microprocessor  and  associated  sequence  of  micro-instructions  necessary  to 
perform  tbs  allocsted  tasks.  As  s  minimum,  the  information  presented  during 
cn&  shall  provide 
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70.  Functional  Configuration  Audit. 

* 

70.1  General.  The  ob}«ctiv«  of  the  Functional  Configuration  Audit  (FCA) 
shall  be  to  verify  that  the  configuration  i ton's  actual  performam  coaplles 
with  itc  hardware  Development  or  Software  Requirements  and  Interfc  so 
Requirements  Specifications.  Test  data  shall  be  reviewed  to  eerli  that  the 
hardware  or  coaputer  software  performs  as  required  by  its  functionai/allocated 
configuration  identification.  For  configuration  ItesM  developed  at  Ooveramant 
expense,  an  FCA  shall  be  a  prerequisite  to  acceptance  of  the  configuration 
iten.  For  software,  a  technical  understanding  shall  be  reached  on  the 
validity  and  the  degree  of  coapleteness  of  the  Software  Test  Reports,  and  as 
appropriate.  Computer  System  Operators  manual  (C80H),  Software  User's  Manual 
(SUM) ,  and  Computer  system  Diagnostic  Manual  (CSDH). 

70.1.1  The  FCA  for  a  complex  configuration  item  may  be  conducted  on  a 
progressive  basis,  when  so  specified  by  the  contracting  agency,  throughout  the 
configuration  item's  development  and  culminates  at  the  cospletion  of  the 
qualification  testing  of  the  configuration  item  with  a  review  of  all 
discrepancies  at  the  final  FCA.  The  FCA  shall  be  conducted  on  that 
configuration  of  the  configuration  iten. which  is  representative  (prototype  or 
preproduction)  of  the  configuration  to  be  released  for  production  of  the 
operational  inventory  quantities.  Mien  a  prototype  or  preproduction  article 
is  not  produced,  the  FCA  shall  be  conducted  on  a  first  production  article. 

For  cases  where  configuration  itesi  qualification  can  only  he  determined 
through  integrated  system  testing,  FCA'*  fot  such  configuration  items  will  SK»t 
be  considered  complete  until  coapletion  of  such  integrated  testing* 

70.1.2  Recommendations  of  configuration  item  acceptance  or  non-acceptance  to 
the  local  contract  management  agency  are  based  upon  and  governed  by  procedures 
and  requirements  outlined  in  subsequent  paragraphs. 

70.1.3.  Continuing  with  the  results  of  the  critical  Design  Review  (CDR), 
review  engineering  data  as  defined  in  para  3.15,  as  to  the  suitability  for 
intended  use.  The  review  should  consider  the  checklist  items  discussed  in 
para  100.6,  as  properly  tailored. 

70.2  Contract  Requirements 

70.2.1  The  schedules  for  the  FCA  shall  be  recorded  on  the  configuration  item 
development  record  by  the  contractor.  A  configuration  iten  cannot  be  audited 
without  the  contracting  agency  authentication  of  the  functional  and  allocated 
baseline,  in  addition,  the  contractor  shall  submit  the  final  draft  Product 
Specification  for  the  configuration  item  to  be  audited  to  the  contracting 
agency  for  review  prior  to  FCA. 

70.3  contractor  Responsibility 

70.3.1  Prior  to  the  FCA  date  (for  configuration  items  to  be  audited),  the 
contractor  shall  provide  the  following  information  to  the  contracting  agency 
(this  information  shall  be  provided  in  addition  to  the  general  requirements  of 
Section  4. ) : 
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4.  Casf  caetot  representation (tbe  test  manager  should  be  is  attendance), 

b.  Identification  of  it** a  to  b«  audited: 

(1)  Bcasaciatare 

(2)  Specification  identification  number 

(3)  Configuration  ltea  nuaber 

(4)  Current  listing  of  all  deviations/waivers  against  tbe 
configuration  item,  either  requested  of,  or  approved  by  the  contracting  agency. 

(5)  Status  of  Test  Progran  to  test  configured  iteas  with  automatic 
test  equipment  (when  applicable). 

70.4  Procedures  end  Requirements 

70.4.1  The  contractor's  test  procedures  and  resulta  shall  be  reviewed  for 
ooaq>liance  with  specification  requirements. 

70.4.2  Tbe  following  teatlng  Information  shall  be  available  for  the  PCA  tew. 

a.  Test  plana,  specifications,  descriptions,  procedures,  end  reports  for 
tbe  configuration  itea. 

b.  A  complete  list  of  successfully  accomplished  functional  tests  during 
which  pre-acceptance  data  was  recorded. 

c.  A  complete  list  of  successful  functional  tests  if  detailed  teat  data 
are  not  recorded. 

d.  A  complete  list  of  functional  teats  required  by  the  specification  but 
not  yet  performed.  (To  be  performed  as  a  system  or  subsystem  test). 

*.  Preproduction  and  production  test  results. 

70.4.3  Testing  accomplished  with  the  approved  test  procedures  and  validated 
data  (witnessed)  shall  be  sufficient  to  insure  configuration  item  performance 
•a  set  forth  in  tbe  specification  Section  3  and  meet  the  quality  assurance 
provisions/qualification  requirements  contained  in  the  specification  Section  4. 

70.4.4  Tor  those  performance  parameters  which  cannot  completely  be  verified 
during  tasting,  adequate  analysis  or  simulation  shall  have  been  accomplished. 
Tbe  results  of  tbe  analysis  or  simulations  will  be  sufficient  to  insure 
configuration  item  performance  as  outlined  in  the  specification. 
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70.4,5  Teat  reports,  procedures,  and  date  used  by  tbe  PCA  teas  shall  be  Bade 
a  natter  of  record  in  tbe  FCA  minutes. 

70.4*6  A  list  of  tbe  contractor's  internal  docunentatlon  (drawings)  of  tbe 
configuration  iten  shall  be  reviewed  to  insure  that  tbe  contractor  has 
documented  tbe  physical  configuration  of  tbe  configuration  item  for  which  tbe 
test  data  are  verified. 


70.4.7  Drawings  of  BWCI  parte  which  are  to  be  provisioned  should  be 
selectively  saapled  to  assure  that  tast  data  essential  to  manufacturing  are 
included  on,  or  furnished  with,  tbe  drawings. 

70.4.8.  Configuration  It  cm  (els)  which  fail  to  pass  guality  assurance  taat 
provisions  are  to  be  analysed  as  to  tbe  cause  of  failure  to  pass.  Appropriate 
corrections  shell  be  Bade  to  both  the  Cl  and  associated  engineering  data 
before  a  Cl  is  subjected  to  requalification. 

70.4.9  A  checklist  shall  be  developed  which  identifies  docunentation  and 
hardware  and  computer  software  to  be  available  and  tasks  to  be  accoapliabed  at 
the  PCA  for  tbe  configuration  item.  See  Pre-PCA  checksheet. 


70.4.10  Retesta  or  additional  tests  shall  be  performed  to  assure  cosplirno* 
with  paragraph  70.4.3. 


ACfciiufricuyc  ateunplishnent  Of  partial  ewfiliilau  uf  tbw  PCA  xuf  tnuaw 
configuration  items  whose  qualification  is  contingent  upon  completion  of 
integrated  systems  testing. 


70.4.12  Por  CSC Is  the  following  additional  requirements  shall  apply: 


a.  The  contractor  shall  provide  the  FCA  team  with  a  briefing  for  each 
CSC I  being  audited  and  shall  delineate  the  test  results  and  findings  for  each 
CSCI.  As  a  minimum,  the  discussion  shall  include  CSCI  requirements  that  were 
not  met,  including  a  proposed  solution  to  each  Item,  an  account  of  the  SCPs 
incorporated  and  tested  as  well  as  proposed,  and  a  general  presentation  of  tbe 
entire  CSCI  test  effort  delineating  problem  areas  as  well  as  accomplishments. 

b.  An  audit  of  the  formal  test  plans/descriptions/procedures  shall  be 
made  and  compared  against  the  official  test  data.  Tbe  results  shall  be 
checked  for  completeness  and  accuracy.  Deficiencies  shall  be  documented  and 
made  a  part  of  the  PCA  minutes.  Completion  dates  for  all  discrepancies  shall 
be  clearly  established  and  documented. 


c.  An  audit  of  the  Software  Test  Reports  shall  be  performed  to  validate 
that  the  reports  are  accurate  and  completely  describe  the  CSCI  tests. 
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d.  All  ECP»  tb.it  have  been  Approved  shall  be  reviewed  to  ensure  that 
they  have  been  technically  incorporated  and  verified. 

«»  All  updated  to  previously  delivered  documents  shall  be  reviewed  to 
ensure  accuracy  and  consistency  throughout  the  doc users  tat ion  a*t. 

f .  Preliminary  and  Critical  Design  Review  minutes  shall  be  examined  to 
ensure  that  all  findings  have  been  incorporated  and  c completed. 

g.  The  interface  requirements  and  the  testing  of  these  requirements 
shall  be  reviewed  for  CSCIs. 

b.  Review  data  base  characteristics,  storage  allocation  data  nnd  timing, 
and  sequencing  characteristics  for  compliance  with  specified  requirements. 

70.5  Post  Audit  Actions 


70.5.1  After  completion  of  the  fca,  the  contractor  shall  publish  and 
distribute  copies  of  FCA  minutes.  She  contracting  acpney  officially 
acknowledges  completion  of  the  FCA  as  indicated  in  paragraph  4.2.4. 

70.5.2  The  accomplishment  of  tbe  FCA  shall  be  recorded  on  the  configuration 
item  Development  Record  by  the  contractor. 


(Reprinted  without  change) 


74 


HIL-STD-1521B 
APPENDIX  E 
19  Dec  1985 


80. 


Physical  Configuration  Audit  (PCA) 


80.1  General.  The  Physical  Configuration  Audit  (PCA)  aball  be  the  formal 
examination  of  the  a* -built  version  of  a  configuration  item  against  its  design 
documentation  in  order  to  establish  the  product  baseline.  After  successful 
completion  of  the  audit,  all  subsequent  changes  are  processed  by  engineering 
change  action.  The  PCA  also  determines  that  the  acceptance  testing 
requirements  prescribed  by  the  documentation  is  adequate  for  acceptance  of 
production  units  of  s  configuration  its*  by  quality  assurance  activities.  The 
PCA  includes  a  detailed  audit  of  engineering  drawings,  specifications, 
technical  data  and  tests  utilised  in  production  of  HWCXs  and  a  detailed  audit 
of  design  documentation,  listings,  and  manuals  for  CSCls.  The  review  shall 
include  an  audit  of  the  released  engineering  documentation  and  quality  control 
records  to  make  sure  the  as-build  or  as-coded  configuration  is  reflected  by 
this  docus  .station.  For  software,  the  Software  Product  Specification  and 
Version  Description  Document  shall  be  a  part  or  the  PCA  review. 


80.1.1  The  PCA  shall  be  conducted  on  the  first  article  of  configuration  items 
and  those  that  are  a  reprocurement  of  a  configuration  item  already  in  the 
inventory  shall  be  identified  and  selected  jointly  by  tbe  contracting  agency 
and  the  contractor.  A  PCA  shall  be  conducted  on  the  first  configuration  Item 
to  be  delivered  by  a  new  contractor  even  though  PCA  was  previously 
accomplished  on  the  first  article  delivered  by  a  different  contractor. 


oB.1.2  Formal  approval  by  the  contracting  agency  of  the  configuration  Item 
Product  specification,  and  the  satisfactory  completion  of  a  PCA  results  in 
establishment  of  the  product  baseline. 


80.1.3  Recommendations  of  configuration  item  acceptance  or  nonacceptance  to 
the  responsible  contract  administration  office  (CAO)  are  based  upon  and 
governed  by  procedures  and  requirements  outlined  in  subsequent  paragraphs. 


80.1.4  A  final  review  shall  be  made  of  all  operation  and  support  documents 
(i.e..  Computer  system  Operator's  Manual  (CSMOM),  software  User's  Maual  (SOM), 
Computer  System  Diagnostic  Manual  (CSDM),  Software  Programmer's  Manual  (SPK), 
Firmware  Support  Manual  (FSM))  to  check  format,  completeness,  and  conformance 
with  applicable  data  item  descriptions. 

80.1.5.  Continuing  with  the  results  of  the  Functional  Configuration  Audit 
(PCA),  review  engineering  data  as  defined  in  para  3.15,  as  to  the  suitability 
for  intended  use.  The  review  should  consider  the  checklist  items  discussed  in 
par:s  100.6,  as  properly  tailored. 


80.2  Contract  Requirements 


30.2.1  The  schedules  tor  the  PCA  shall  be  recorded  on  the  configuration  item 
Development  Record  by  the  contractor .  A  current  set-  of  listings  shall  be 
provided  for  each  CSCI  being  audited.  The  contractor  shall  submit  the  final 
draft  of  the 
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product  specification  for  the  configuration  item  to  be  audited  to  the 
contracting  agency  for  review  prior  to  pca. 

BO. 3  Contractor  ftesponsibilifcy 

60.3.1  The  contractor  shall  provide  the  following  Information  to  the 
contracting  agency  (this  lnfonaation  shall  be  provided  in  accordance  with  the 
general  instructions  cf  Section  4  and  the  contraetural  requirements): 

a.  Contractor  representation  (the  test  manager  should  be  in  attendance). 

b.  Identification  of  items  to  be  accepted  by: 


(1) 

Nomenclature 

(2) 

Specification  Identification 

Number 

(3) 

Configuration  item  Identifiers 

(4) 

serial  Numbers 

(5) 

brewing  and  Part  Numbers 

(6) 

Identification  Numbers 

(7) 

Code  Identification  Numbers 

(8) 

Software  inventory  numbering 

system 

c.  A  list  delineating  all  deviatione/waiverc  against  the  configuration 
item  either  requested  or  contracting  agency  approved. 

80.3.2  The  pr*~  cannot  be  performed  unless  data  pertinent  to  the  configuration 
item  being  »u  ted  is  provided  to  the  PCA  team  at  time  of  the  audit.  The 
contractor  shall  compile  and  make  this  information  available  for  ready 
reference.  Required  information  shall  include: 

a.  configuration  item  product  specification. 

b.  A  list  delineating  both  approved  and  outstanding  changes  against  the 
configuration  item. 

c.  Complete  sho'-'-age  list. 

d.  Acw^ptance  cest  procedures  and  associated  test  data. 

e.  Engineering  drawing  index  including  revision  letters. 
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non— complex  system  >oae  reviews  My  not  be  required*  or*  if  required*  m;  be 
limited  in  Scope.  The  tailoring  procedures  discussed  earlier  should  result 
either  in  the  exclusion  of  Klb-STD-1521  or  in  s  tailored  *ll#-ETD-1521  that 
reflects  a  limited  scope  technical  review  effort.  Conversely*  in  a  very 
complex  development  the  review  process  will  increase  in  levels  and  numbers  of 
reviews. 

b.  In  addition  to  the  above,  the  degree  of  application  is  dependent  upon 
the  configuration  iten  state  of  development  (example*  new  design  va. 
commercially  available)  or  the  degree  of  any  modifications*  if  involved*  For 
example:  a  newly  developed  iten  may  require  the  majority  of  the  review 
topica/i terns  and  audits,  while  a  commercially  available  configuration  item 
with  the  appropriate  documentation,  i.e.*  verified  test  results* 
specifications*  drawings,  etc.  may  require  reviews  or  audits  limited  to  its 
application  to  the  program  and  its  interfaces.  In  the  case  of  modified 
designs  one  must  consider  the  degree  and  effect  of  the  modifications.  Reviews 
and  audits  may  be  limited  to  the  modifications  and  their  Interfaces. 

100.5  scheduling  of  Technical  Reviews  and  Audits 

The  schedule  for  Technical  Reviews  and  kudit*  is  extremely  important.  If  they 
are  conducted  too  early*  the  item  for  review  will  not  be  adequately  defined. 
Conversely*  if  the  review  is  too  late*  the  program  commitments  could  have  been 
made  erroneously*  and  correction  will  be  both  difficult  and  costly.  For 
planning  purposes,  a  good  method  for  scheduling  technical  reviews  is  to  relate 
them  to  the  documentation  requirements.  For  example*  schedule  a  PDR  after  the 
hardware  Development  Specification  or  Software  Top  bevel  Design  Document  and 
Software  Test  Plan  are  available ,  since  the  essence  of  the  PDR  is  to  assess 
the  contractor's  approach  to  meeting  these  requirements  of  these  documents. 
Scheduling  of  audits  are  dependent  not  only  on  documentation  availability  but 
also  on  hardware/software  availability*  and  the  completion  of  the  acceptance 
qualification  tests.  Table  1  contains  a  list  of  the  primary  documentation 
associated  with  each  review  or  audit  and  the  estimated  time  phasing: 

100.6.  Tailoring  Guidance  for  Engineering  Data  Reviews.  Engineering  Data 
reviews  are  conducted  as  part  of  the  formal  design  reviews/audits  in 
MIL- STD-1521 •  Dae  Figure  5*  Review  Checklist  for  Engineering  Data,  to  help 
prepare  for  and  conduct  these  reviews  and  audits.  Rote  discrepancies  on 
Figure  6,  Engineering  Data  Discrepancy  sheet.  Beccuse  reviews  and  audits  are 
successively  more  detailed,  more  items  on  the  checklist  will  apply  as  the 
program  progresses.  When  all  reviews  and  audits  are  completed,  all  items  cn 
the  tailored  checklist  should  be  accomplished. 
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TABLE  1 

BCKKHJLIHG  REVIEWS  AMD  AUDITS 

Tine  Phase  Primary  Bocugent»tlon 

Dsually  accoaplished  ir  the  Various  analysis  and 

Concept  Exploration  ph_*c.  trade  study  reports  used 

However,  nay  be  used  in  to  develop  the 

other  phases  when  the  sysfcea/sevaent 
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110.  Production  Rgsdlngaa  Revlsy  (PMU 

110.1  For  specific  pldaccc,  see  AFSCR  84-2,  Production  Readiness  terlw. 
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REVIEW  CHECKLIST  FOR  EBGIBSERIBG  DATA 


1*  19m  following  questions  sod  considerations  should  be  used  prior  to 

conducting  *n  engineering  date  review.  These  are  suggested  guidelines,  and 
should  be  used  as  such. 

XX.  Pre-briefing  preparation: 

a.  Answer  these  questions; 

1.  What  is  the  purpose  of  the  Review? 

2.  What  does  the  Contract  require? 

3.  bow  will  the  drawings  be  used? 

b.  Arrange  briefings; 

1.  The  Contractor  shall  brief  the  tean  on  contractual  requirements 
and  atatua. 

2.  The  Engineering  Data  Management  Officer  (ED HO)  or  Chairperson 
should  brief  the  team  ar.  the  review  procedures. 

3.  Discuss  corrective  action  procedures. 

XXX.  The  nets  Review: 

a.  Build  the  package: 

1.  Select  sample  of  top  assembly  drawings. 

2.  Look  at  Parts  List  of  the  top  assembly  or  ma^or  subassembly 


drawings. 


Are  other  subassembly  drawings  listed  in  the  top  parts  list? 
Are  all  drawings  listed  in  the  top  ports  list  available? 


5.  Are  all  drawings  listed  in  the  subsssentbly  parte  list  available? 
6*  is  manufacturing  planning  documentation  available? 
b.  Examine  the  engineering  data  for  the  following: 

1.  It  the  drawing  legible  and  suitable  for  reproduction? 

2.  Are  processes/specif ications  listed? 

3.  Look  at  notes  on  all  drawings.  Are  all  notes  understandable? 
Are  notes  clear  and  concise? 

4.  Are  peculiar  symbols,  abbreviations,  etc,,  explained? 

5.  Are  all  dimensions  and  tolerances  shown? 

6.  is  the  materiel  identified? 

7.  Are  any  reports  referenced?  If  so,  are  they  supplied  in  the 


package? 

H. 

the  package? 

9. 

10. 


Arc  copies  of  non-government  specifications  supplied  as  prrt  of 


9.  Correct  use  or  limited  rights  legends  (DAR/FAR)? 

10.  Are  control  drawings  (particularly  Source  and  Specification 
Control)  properly  used  and  marked?  (DOD-STD-1UO? 

11.  Are  hardness  critical  items  and  hardness  critical  process 
markings  correct? 

12.  Are  electrostatic  discharge  sensitive  (ESD5)  symbology  and 
cautions  included,  as  appropriate? 

13.  save  changes  been  incorporated  as  required  in  the  contract? 
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14*  Ace  index  and  data  lists  available  and  correct? 

ISo  Is  there  a  distribution  statement  on  each  piece  of  engineering 

data? 

16.  Bave  specific  narking  requirement*  (KIL-STI)-130)  been  defined? 

17.  Are  acceptance  test  requirnments  included  or  all 
oubareeably/detail  drawing*  for  items  that  night  be  spared  separately  by 
competitive  reprocurement7 

18.  is  the  proper  engineering  design  infomation  Included  for  the 
level  of  drawing  statad  in  the  contract? 

19.  Could  a  military  standard  or  specification  be  used  in  lieu  of 

drawings? 

20.  Are  applicable  security  classifications  marked  correctly? 

21.  Are  the  contractual  requirements  adequate? 

22.  Poes  the  drawing  package  appear  to  be  adequate  to  support  the 
intended  end  use  (i.e.  logistics  support,  competitive  reprocuresent ,  etc)? 

c.  Record  all  deficiencies/discrepancies  on  the  Engineering  Data 
Discrepancy  Sheet  (a»e  Figure  6)  in  sufficient  detail  to  cospletaly  define  the 
problem  and  action  required  for  compliance. 

At  the  end  of  the  review,  the  ECHO  (or  Review  Team  Chief)  collects  all 
discrepancy  sheets,  signs  them,  and  determine*  appropriate  disposition.  After 
resolution  of  discrepancies,  the  sheets  will  be  filed  in  the  Engineering  Data 
Files. 
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Fiona  6 


(PROGRAM  HAKE) 


Sheet  of 


Engineering  Data  Discrepancy  Sheet 
(To  be  used  with  the  Review  Checklist) 


PRIME  AHD  SOBCOimUCTOR/VENDOR  NAME: 


TIPS  OF  REVIEW; 


REVIEWER'S  NAME 


DRAVilNG/DOCDMENT  NUMBER 


DISCREPANCIES 


ACTION  REQUIRED/ COMPLIANCE 


PROGRAM  OFFICE  EDMO  (cr  Team  Chief)  Signature 


AIR  LOGISTICS  EDMO  SIGNATURE 


ACTION  AGENCY: 


jContractor 

Contract  Administration  Office 


rhifc  block  to  be  used  by  Action  Agency 


DISCREPANCIES  CORRECTED  BY; 


(Signature) 


After  resolution,  return  to  the  Program  Office  EDMO 


I  REV  DATE 


DOE  DATE 


Program  Office 
Other 


(Date) 
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FOREWORD 


1.  This  military  standard  is  approved  for  use  by  all  Departments  and  Agencies  of  the  Department  of  Defense. 

2.  Beneficial  comment:  (recommendations,  additions,  deletions)  and  any  pertinent  data  which  may  be  of  use 
in  improving  this  document  should  be  addressed  to:  AFMC/FMA,  Wright-Patwrson  Air  Force  Base,  Ohio 
45433,  by  using  the  self-addressed  Standardization  Document  improvement  Proposal  (DD  Form  1426)  appearing 
at  tire  end  of  the  document  or  by  letter. 

3.  This  military  standard  is  applicable  to  all  defense  materiel  items  (or  major  modifications)  (a)  established  as 
an  integral  program  element  of  the  Future  Years  Defense  Program  (FYDP),  or  (b)  otherwise  designated  by  the 
DoD  Compancoe  or  the  Under  Secretary  of  Defense  (Acquisition). 

4.  The  practices  and  procedures  contained  in  this  standard  are  applicable  to  systems,  equipment,  and  other 
designated  materiel  items  which  are  referred  to  as  defense  materiel  items.  Work  breakdown  structures  (WBS) 
provide  a  consistent  and  visible  framework  for  defense  materiel  items  (as  well  as  contracts  within  a  program) 
that  facilitate: 


a.  A  me  re  effective  management  and  technical  base  for  planning  and  assigning  management  and  technical 
responsibilities  within  government  offices  responsible  for  the  acquisition  of  defense  materiel  items  and 
contractors  furnishing  the  items. 


b.  The  basis  for  communication  throughout  the  acquisition  process  by  providing  the  common  link  unifying 
the  planning,  scheduling,  cost  estimating,  budgeting,  contracting,  configuration  management,  and  performance 
reporting  disciplines. 

c.  More  consistent  control  over  and  reporting  of  the  progress  and  status  of  engineering  and  other  contractor 
efforts,  resource  allocations,  cost  estimates,  expenditures,  and  procurement  actions  throughout  the  acquisition  of 
defense  materiel  items. 


d.  Acquisition  decisions  which  consider  total  life  cycle  effects,  including  development,  production, 
activation,  operational  use,  and  phase-out. 

5.  The  uniformity  iu  definitions  and  approach  for  developing  the  top  three  levels  of  the  work  breakdown 
structure  established  by  tins  standard  is  expected  to  assure  compatibility  of  multiple-data  requirements.  The 
benefits  expected  from  increased  uniformity  in  the  generation  of  work  breakdown  structures  and  their 
application  to  management  practices  will  be  realized  by  die  improved  interpretation  and  reconciliation  of  all 
reports  prepared  to  this  uniform  framework  throughout  the  acquisition  of  a  defense  materiel  item. 

6.  This  military  standard  is  baaed  on  the  cooperative  efforts  of  the  military  services  with  assistance  from 
industrial  associations. 
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1.  SCOPE 

1.1  Purpose.  This  siandaro  esabli&bes  criteria  governing  the  preparauon  and  employment  of  work  breakdown 
structures  for  use  during  the  acquisition  of  designated  defense  materiel  items  to  display  and  d^fitw  the  products 
to  be  developed  or  produced. 


1.2  Application. 

1.2.1  The  work  breakdown  structure  requirements  established  by  this  standard  are  solely  with  the 

acquisition  of  defense  materiel  items  (or  major  modifications)  that  are  (a)  established  as  an  integral  program 
element  of  the  Future  Years  Defense  Program  (FYDP),  or  (b)  otherwise  designated  by  the  DuD  or 

the  Under  Secretary  of  Defense  (Acquisition).  Specifically,  it  pertains  to  only  those  elements  of  research  and 
development  and  investment  that  are  applicable  to  contracted  efforts. 

1 .2.2  This  standard  is  to  be  used  by  both  contractors  and  DoD  Components  (Government  activities)  in  the 
development  of  work  breakdown  structures  for  me  acquisition  of  defense  materiel  items. 

1.2.3  Work  breakdown  structures  in  use  on  existing  programs  will  continue  to  be  used  on  these  programs 
unless  it  is  considered  mutually  advantageous  to  the  Government  and  the  contractors)  to  apply  this  standard. 
Approval  for  substitution  should  follow  guidance  in  paragraph  4. 1. 1. 


m 
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2.  APPLICABLE  DOCUMENTS 


2.1  Government  Documents. 

2.1.1  Specifications  Standards.  and  Handbooks.  This  section  is  not  applicable  to  this  standard. 

2.1.2  Other  Government  Documents.  Drawing,  and  Publications.  The  following  other  Government 
documents,  drawings,  and  publications  form  a  part  of  this  document  to  the  extent  specified  herein.  Unless 
otherwise  specified,  the  issues  are  these  cited  in  the  solicitation. 

PAMPHLETS 

Contractor  Cost  Data  Reporting  (CCDR) 

NAVMAT  P-5241  Navy  Materiel  Command  Peaphlet 
AMC-P  715-3  Army  Materiel  Command  Pamphlet 

AFLC'P  800-15  Air  Foicc  Logistics  Command  Pamphlet 

AFSCP  800  15  Air  Force  Systems  Command  Pamphlet 

Cost/Schedule  Control  System  Criteria  Joint  Implementation  Guide 

NAVSG  P3627  Assistant  Secretary  of  the  Navy  (S&L)  rnmphlet 

APSCP  173-5  Air  Force  Systems  Command  Pamphlet 

AFCCP  173-5  Air  Force  Communications  Command  Pamphlet 

AFLCP  173-5  Air  Force  Logistics  Command  Pamphlet 

AMC-P  715-5  Army  Materiel  Command  Pamphlet 

DLAB  8400.2  Defense  Logistics  Agency  Handbook 

DCAA  P7641.47  Defense  Contract  Audit  Agency  Pamphlet 

(The  above  pamphlet  mimbeis  identify  two  single  documents:  Contractor  Cost  Data  Reporting  (CCDR)  System 
(Stock  Number  0518LP1003001),  and  Cost/Schedule  Control  Systems  Criteria  Joint  Implementation  Guide 
(Stock  Number  0518LP1002010).  These  two  documents  can  be  ordered  by  stock  number  from  the 
Standardization  Documents  Order  Desk,  700  Robbins  Avenue,  Building  #4,  Section  D,  Philadelphia,  PA  1911!- 

5094. 

2.2  Non-Government  Publications.  This  section  is  not  applicable  to  this  standard. 

2.3  Order  of  Precedence  In  the  event  of  a  conflict  between  the  text  of  this  document  and  the  references  cited 
herein,  the  tex;  of  this  document  takes  precedence.  Nothing  in  this  document,  however,  supersedes  applicable 
laws  and  regulations  unless  a  specific  exemption  has  been  obtained. 
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3.  DEFINTnONS 

3. 1  General.  Terms  will  be  as  defined  herein  and  in  the  appendices  of  this  document. 

3.2  Program  Elaosnt.  A  program  element  is  the  basic  building  block  of  the  Future  Years  Defense  Program 
(FYDP).  It  is  a  description  of  the  mission  to  be  undertaken  and  a  list  of  the  organizational  entities  iri.mrifiwt  to 
perform  the  mission  assignment.  A  program  element  may  consist  of  forces,  manpower,  materiel  (both  real  and 
personal  property),  .services,  and  associated  costs,  as  applicable.. 

3.3  Defense  Materiel  Item.  Defense  materiel  item  is  h  teem  used  within  the  DoD  to  identify  a  system  or  item 
that  is  usually  established  as  an  integral  program  element  or  is  identified  as  a  project  within  an  aggregated 
program  element. 

3.4  Work  Breakdown  Structure.  A  work  breakdown  structure  (WDS)  is  a  nrodoa-orieuted  family  tree 
composed  of  hardware,  software,  services,  dam  and  facilities  which  results  from  systems  engineering  efforts 
during  tte  acquisition  of  a  defense  materiel  item.  A  work  breakdown  structure  displays  and  defines  the 
piodnct(s)  to  be  developed  and/or  produced  and  relates  the  el«nimrc  of  work  to  be  accomplished  to  otter 
and  to  the  end  produces).  The  work  breakdown  structures  prescribed  by  this  standard  have  been  organized 
within  the  seven  categories  of  defense  materiel  items  and  consist  of  the  upper  three  levels  of  the  work 
breakdown  structure. 

3  4. 1  Categories  of  Defense  Materiel  Items  The  seven  categories  of  defense  materiel  items  identified  in  3.4 
are  as  follows: 


a.  Aircraft  Systems 

b.  Electronic/ Automated  Software  Systems 

c.  Missile  Systems 

d.  Ordnance  Systems 

e.  Ship  Systems 

f.  Space  Systems 

g.  Surface  Vehicle  Systems 

3.4.2  level  identification.  The  three  work  breakdown  structure  levels  specified  in  3.4  are  as  follows: 

Level  1:  Level  1  is  the  entire  defense  materiel  item;  for  example,  die  M  mu  reman  ICBM  System  or  the 
LHA  Ship  System.  Level  1  is  usually  directly  identified  in  the  DoD  programming /budget  system  either 
as  an  integral  program  dement  or  as  a  project  or  subprogram  within  an  aggregated  program  element. 

Level  2;  Level  2  element:  are  major  elements  o*  the  defense  materiel  item  ami  are  subordinate  to  level 
1;  tor  example,  a  ship,  an  air  vehicle,  a  tracked  vehicle,  and  aggregations  of  services  (such  as  system 
test  and  evaluation,  and  systems  engineering/program  management)  and  data. 

Level  3:  Level  3  dements  are  clancim  subordinate  to  level  2  mejor  demeans;  for  example,  an  electric 
plant,  an  airframe,  tire  power  package/ drive  train,  or  type  of  service  (such  as  development  test  and 
evriuatioa,  contractor  technical  support,  training  cervices),  or  type  of  data  (socb  «t  technical 
publications),  lower  levels  follow  the  same  process. 

3.5  Program  Work  Breakdown  Structure,  a  program  work  breakdown  structure  is  defined  as  the  work 
breakdown  structure  that  covers  the  acquisition  of  a  specific  defense  materiel  item  and  is  related  fr>  contractual 
effort.  A  program  vork  breakdown  structure  includes  all  applicable  elements  consisting  of  at  beast  the  first 
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three  levels  of  the  work  hrcakuov/n  structure  and  extended  by  the  DoD  Component  (program  manager)  and/or 
coraractoits).  A  program  work  breakdown  structure  has  uniform  element  terminology,  definition,  and 
placeman  in  the  family  tree  structure. 

3.6  Contract  Work  Breakdown  Structure  A  contract  vork  breakdown  structure  is  defined  as  the  complete 
work  breakdown  juncture  for  a  contract.  It  includes  the  DoD  approved  work  breakdown  structure  lor  repenting 
purpose!  and  its  discretionary  extension  to  the  lower  levels  by  the  contractor,  in  accordance  with  this  standard 
and  the  contract  work  statement.  It  includes  all  the  elements  for  die  products  (hardware,  software,  data,  or 
services;  which  are  the  responsibility  of  the  contractor. 

3.7  Work  Breutalrmp  Structure  Element.  A  twrt  breakdown  structure  element  is  a  discrete  portion  of  a  work 
breakdown  structure.  A  work  breakdown  structure  cl  totem  may  be  an  identifiable  item  cl  hardware,  software, 
services,  duta  or  facilities. 

3.8  StKfwms  fiagagnag  Systems  asgin  enng  is  defined  as  a  comprehenrivt,  •relative  technical  management 
process  to: 


a.  Translate  an  operational  need  into  a  configured  system  meeting  that  need  through  a  systematic, 
concurrent  approach  to  integrated  design  of  the  system  and  its  related  manufacturing,  test,  and  support 
processes; 

b.  integrate  the  technical  inputs  of  the  entire  development  community  and  all  technical  disciplines 
(including  the  concurrent  engineering  of  manufacturing  logistics,  and  test)  into  a  coordinated  effort  that  meets 
established  program  cost,  schedule,  and  performance  objectives; 

c.  Ensure  the  compatibility  of  all  functional  and  physical  interfaces  (internal  and  external)  end  ensure 
that  system  definition  and  design  reflect  the  requirements  for  rll  system  elcujenis.  inuuwan:,  suit  ware, 
facilities,  people,  and  data;  and 

d.  Characterize  technical  risks,  develop  risk  abatement  approaches,  and  i educe  technical  risk  through 
early  test  and  demonstration  of  system  elements  (ref.  DoD  Instruction  5000.2), 

3.9  Configuration  Item.  A  configuration  item  is  an  aggregation  of  hardware  or  software  that  satisfies  an  end- 
use  function  and  is  designated  by  the  government  for  separate  configuration  management  (ref.  MH^-STD-973). 

3.10  Acquisition.  Acquisition  is  a  term  used  within  the  DoD  to  denote  the  directed,  funded  effort  that  is 
designed  to  provide  a  new  or  improved  materiel  capability  in  response  to  a  validated  need  (ref  DoD  Directive 
5000.1).  Acquisition  commences  with  the  conceptual  phase  and  is  completed  at  the  end  of  the  production 
phase.  It  excludes  all  operating  and  support  activities. 

3.11  Integration.  Assembly.  Tea  and  Checkout,  See  Appendii  H,  Work  Breakdown  Structure  Definitions, 
Common  Elements  (ref.  page  H-2),  for  a  complete  definition.  In  those  instances  in  which  an  integration, 
assembly,  test  nnd  checkout  eianeut  is  used  (Appendices  A  through  G),  it  :tudc  all  effort  of  technical  and 
functional  activities  associated  with  the  design,  development,  and  production  or  mating  surfaces,  structures, 
equipment,  parts,  materials,  and  software  required  to  assemble  the  level  3  equipment  (hardware/softwKre) 
elements  into  a  level  2  mission  equipment  (hardware/soitware)  as  a  whole  and  not  directly  pan  of  any  other 
individual  level  3  element. 

3.12  Punctipnjil  f-ftti; gorier,.  Although  this  standard  does  not  address  functional  categories,  for  each  woifc 
breakdown  structure  element  there  is  a  functional  breakour.  The  cost  of  any  specified  work  breakdown 
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structure  element  et  ;ny  level  is  composed  of  one  or  more  functional  categories.  Functional  categories  include 
engineerinj’,  tooling,  quality  control,  manufacturing,  uid  purchased  equipment,  and  are  defined  m  Chapter  4  of 
the  referenced  pamphlet.  Contactor  Cost  Data  Reporting  (CCDR)  System.  DoD  regulations  reference  and 
establish  requirements  for  functional  breakouts  on  specified  work  breakdown  structures.  Functional  categories 
are  not  work  breakdown  sti  jeture  elements  and  are  not  to  be  represented  as  such  in  work  breakdown  structures. 

3. 13  bjonreyurriiip  anti  Bt.  i.rrinu  Work  breakdown  structure  elements  can  contain  both  nonrecurring  and 
recurring  effort  Nonrecurring  uffoi  >  includes  all  design,  development,  test  (except  acceptance  testing),  baste 
and  rare  tools,  and  manufacturing  support  to  engineering  for  the  design,  development  and  test  effort.  Recurring 
effort  includes  the  manufacturing  of  Lie  test  and  production  units  (including  acceptance  testing),  sustaining 
inwring  and  sustaining  tooling.  The  DoD  approved  Contractor  Cost  Data  Reporting  (CCDR)  Plan 
establishes  the  requirement?  for  reporting  nonrecurring  and  recurring  breakouts  an  work  breakdown  structures 
specified  for  contractor  cost  data  reporting  to  the  government  Nonrecurring  and  recurring  definitions  are  given 
in  Chapter  4  of  the  referenced  pamphlet,  Contractor  Cost  Data  Reporting  (CCDR)  System. 
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n.  GENERAL  REQUIREMENTS 

4. 1  p.eLirinat^in.s  The  structures  and  definitions  contained  in  this  standard  shall  be  the  basis  for  structures 
used  for  contracts  requiring  compliance  with  the  Cost/Schedule  Control  Systems  Criteria  (C/SCSC),  per  DoD 
instructions,  and  the  reporting  systems  of  Cos*  Performance  Reports  (CPR).  Contract  Pucris  Status  Reports 
(CFSR),  Cost/Schedule  Status  Reports  (C/SSR),  and  Contractor  Cast  Data  Reporting  (CCDR).  This  section 
summarises  the  overall  relationship  between  this  standard  and  shore  policy  issuances.  Consult  the  DoD 
regulations  lor  insniKfinns  related  to  tl»e  tefeccnocd  dncwncaes. 

4.1.1  Contractor  Cost  Data  Reporting  (CCPRLHse,  The  CCDR  Plan  procedures  in  DoD  regulations  are  the 
framework,  far  work  breakdown  structure  uevsiepnent  and  approval.  Those  procedures  begin  during  the 
development  of  dx  Statement  of  Wort  (SOW)  and  before  the  ismcnce  of  solicitations  to  indnshy  for  advanced 
development  prototype  arel/oi  engineering  and  manufacturing  development  contracts  and  contiime  through  the 
completion  of  the  production  program.  The  CCDR  Plan,  as  a  key  integration  planning  document  tor  a 
program,  shall  be  used  by  DoD  Components  to  ensure  that  program  work  breakdown  structures  are  developed 
in  accordance  with  tins  standard.  This  planning  process  is  extremely  important  since  die  resulting  approved 
program  work  breakdown  structure  (1)  defines  the  program  and  (2)  is  used  to  organize  the  solidtation(s)  and 
identify  for  prospective  contractors  the  upper  level  contract  work  breakdown  structure.  The  final  contract  work 
breakdown  structure,  incorporating  any  changes  negotiated  with  the  contractor,  is  the  basis  ftw  comma 
organization.  The  statement  cf  work,  contract  line  items,  and  reporting  requirements  roust  all  be  consistent  with 
the  program  work  breakdown  structure  approved  in  the  CCDR  Plan. 

4.1.2  Cost/Schedule  Control  Systems  Criteria  (C/SCSC).  When  a  contract  requires  that  a  contractor’s  cost  and 
schedule  management  control  system  comply  with  the  C/SCSC  requirements  identified  in  DoD  instructions,  the 
system  is  reviewed  to  ensure  that  the  contract  work  breakdown  structure  is  used  as  the  framework  for 
organization,  planning,  budgeting,  accounting,  analysis,  and  revision  of  all  contract  work.  The  C/SCSC  does 
not  establish  the  adequacy  of  {he  contract  work  breakdown  structure.  The  contract  work  breakdown  structure 
contained  in  the  contract  is  based  on  the  approved  CCDR  Plan  (or  the  DoD  Component  approved  plan,  if 
appropriate).  Contract  work  breakdown  structure  development  begins  before  a  solicitation  is  released  to 
industry.  After  contract  award,  C/SCSC  compliance  reviews  ensure  that  the  contractor  is  using  the  contract 
work  breakdown  snucture  properly  to  manage  the  contract. 

4. 1 .3  Cost  Reports.  The  CCDR,  CPR,  and  C/SSR  forms  require  use  of  contract  work  breakdown  structure 
reporting  elements,  and  the  CFSR  may  require  contract  work  breakdown  structure  element  reporting. 

Submission  of  these  reports  is  required  during  performance  of  applicable  contracts;  certain  CCDR  forms  are 
also  required  with  contractor  responses  to  solicitations.  The  CCDR  Plan  Shows  the  CCDR  submission 
requirements  to  be  incorporated  in  solicitations  and  contracts  and  indicates  other  cost  reporting  requirements, 
such  as  CPR  and  CFSR.  Contractual  reporting  is  through  the  contract  data  requirements  list  (CDRL),  During 
contract  negotiation,  any  needed  adjustments  may  be  proposed  by  either  party.  As  a  general  rule,  routine 
reporting  is  at  level  3  of  the  contract  work  breakdown  structure  (level  2  for  CFSR.,  when  applicable),  except  for 
high-cost,  high-nsk,  or  other  high-interest  elements  that  are  at  lower  levels.  The  appropriate  contract  work  ' 
breakdown  structure  level  specified  for  routine  reporting  shall  be  evaluated  carefully  by  the  DoD  Component 
with  the  contractor  to  ensure  only  the  minimum  amount  of  reporting  necessary  to  achieve  effective  management 
control  is  required. 

4.2  Wqpk  Breakdown  Structure.  The  DoD  Component  shall  develop  a  program  work  breakdown  structure  for 
defense  materiel  items  prior  to  program  initiation  by  selecting  appropriate  elements  from  one  or  more  of  the 
work  breakdown  stnicture(s)  set  forth  in  Appendices  A  through  G  of  this  standard  that  are  applicable  to  the 
program.  Approval  of  this  program  work  breakdown  structure  shall  be  obtained  in  accordance  with  DoD 
regulations  From  this  approved  program  work  breakdown  structure  the  individual  contract  work  breakdown 
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structure(s)  will  be  developed  by  the  DoD  Component  and  negotiated  with  the  contractor^)-  The  negotiated 
contract  work  breakdown  structure(s)  will  then  be  extended  to  lower  levels  by  the  contractor's)  to  define  the 
complete  contract  scope.  Wltcn  aggregated  with  the  program  work  breakdown  structure,  tfiu-  extended  contract 
work  breakdown  structures  shall  form  a  complete  work  breakdown  structure  which  will  be  used  throughout  the 
acquisition  cycle.  Figure  1  depicts  the  evolution  and  relationship  of  the  work  breakdown  stm.'ture(s)  to  the 
various  acquisition  stages. 

4.3  Program  Maiuuiemcnt.  The  program  work  breakdown  structure  and  contract  work  breakdown  structure 
extensions  can  be  used  as  a  framework  for  technical  and  management  activities.  The  program  office  should 
employ  the  program  work  breakdown  structure  and  its  contract  work  breakdown  structure  extensions  as  a 
coordinating  medium  in  planning  for  titsther  sy  items  engineering,  resource  allocation,  tout  estimates,  contract 
actions,  and  work  execution.  The  reporting  of  jirogress,  performance,  and  engineering  evaluations  as  well  as 
financial  data,  shall  be  based  on  Ore  program  work  breakdown  structure. 

4.4  Solicitation  agti  Proposal  .Action.  The  contract  work  hreakdrrwn  structure  used  for  aoficioaioc  will  be 
structured  by  selecting  appropriate  element;  from  the  approved  program  work  breakdown  structure.  The 
contract  line  items,  configuration  items,  contract  statement  of  work  tasks,  contract  specifications,  and  contractor 
responses  will  be  expressed  in  terms  of  the  work  breakdown  structure  to  enhance  its  effectiveness  in  satisfying 
the  objectives  of  the  particular  acquisition.  While  the  relationship  of  the  contract  work  breakdown  so  occurs 
elements  to  the  statement  of  work  tasks  and  the  contract  line  items  should  be  clearly  traceable,  there  may  not  be 
a  one-to-one  relationship,  nor  is  it  required. 

4,  5  Specifications  and  Drawings.  The  family  of  specifications  and  drawings  rcsultii-g  from  the  progressive 
steps  of  systems  engineering  will  conform  to  the  evolved  program  work  breakdown  structure  and  its  extensions. 

4.6  Contractor  Management  Control  System.  The  contract  work  breakdown  sajcturt  shall  serve  as  foe 
framework  for  foe  contractor's  management  control  system  which  shall  provide  atuirabic  and  matahie 
summarcsitions  of  internal  data  generated  by  its  performance  measurement  procedures. 

4.7  Integrated  Logistics  Support  fILS'l.  The  integrated  logistics  support  element  wil'.  r  accommodated  as 
indicated  in  the  upper  levels  of  ch?  work  bteaidorvn  structure  in  Appendices  A  through  G.  Aggregations  of 
work  breakdown  structure  elements  for  logistics  support  management  and  reporting  will  be  accomplished  bv 
summation  of  those  level  2  ILS  elements  which  are  fully  ILS  elements  (that  is,  training,  peculiar  support 
equipment  and  initial  spares)  plus  those  portions  of  level  2  elements  identified  as  ILS  elements  at  level  3  (such 
as  support  date  and  ILS  management). 

4.8  Planrink,  Programming  and  fiudpcting  System,  The  program  work  breakdown  structure  shall  be  used 
wherever  it  is  necessary  to  subdivide  foe  program  element  data  for  foe  planning,  prof^rammiag  and  budgeting 
system.  The  program  work  breakdown  structure  shall  also  be  used  in  cost  estimating  for  future  programs  and 
procurement  actions. 

4.9  Ufc-Cvcie  Cost,  .life  cycle  cost  is  the  total  cost  for  the  research  and  devdapmeiu,  tnwscutmt,  operation 
and  support,  and  disposition  of  a  weapon  or  support  system.  It  commences  at  the  start  of  the  conceptual  stage 
and  ends  with  the  rctiietnecf/deniilitarization  of  the  system  from  foe  inventory.  Hie  work  breakdown  atimsre 
requirements  established  by  this  standard  are  associated  solely  with  foe  acquisition  of  defense  materiel  items  (or 
major  modifications!  and,  specifically,  those  dements  of  research  and  development  and  investment  that  are 
applicable  to  all  contracted  efforts. 
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4.10  Procurement.  The  following  stbili  be  relatafcls  to  elements  of  the  program  work  breakdown  structure: 

a  Structure  of  work  statements 

b.  Contract  work  breakdown  acTumae; 

c.  Coiitraei  ike  items 

d.  Configuration  item^ 

e.  Technical  and  mamgemert  reports 

f.  Govenuceat-fumished  items 

4. 1 1  Reporting.  All  reporting  requirements  for  the  program  shall  be  consistent  with  tb;  program  work 
breakdown  suucoue.  The  organization  of  reporting  requirements  shall  not  b»  construed  by  either  the  DoD 
Component  or  the  contractor  as  determining  the  manner  in  which  the  defense  materiel  item  is  to  be  fO^igrwt  or 
produced. 
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5.  DBT AILED  REQUIREMENTS 

5.1  Work  bicakdown  Structure.  The  appropriate  category  or  categories  of  work  breakdown  structures)  and 
related  definitions  prescribed  herein  shall  be  used  in  the  preparation  of  the  program  work  breakdown  structure 
for  the  specific  defense  materiel  item  under  consideration. 

5.1.!  Aircraft  Systems.  Tbr.  work  breakdown  strucunr.  and  definitions  for  an  aircraft  system  shall  be  as 
specified  in  Appendix  A. 

5.1.2  Electronic' Automated  Software  Systems  The  work  breakdown  structure  and  definitions  for  an 
eiecatmic/autormted  software  system  shall  be  as  specified  in  Appendix  B. 

5.1.3  Missile  Systems.  The  work  breakdown  structure  and  definitions  for  a  missile  system  shall  be  as  specified 
in  Appendix  C. 

5.1.4  (Ini nance  Systems  The  work  breakdown  structure  and  definitions  for  an  ordnance  system  shall  be  as 
specified  in  Appendix  D. 

5.1/  Ship  Systems  The  work  breakdown  stmeture  and  definitions  for  a  ship  system  shall  be  as  specified  in 
Appendix  E. 

5. 1 .6  Snace  Systems.  Tnc  work  breakdown  structure  and  definitions  for  a  space  system  shall  be  as  specified  in 
Appendix  F. 

5. :  7  Surface  Vehicle  Systems.  The  work  breakdown  structure  and  definitions  for  a  surface  vehicle  system 
iha'l  be  as  specified  in  Appendix  G. 


5.2.1  Preparation.  "Hie  program  work  breakdown  structure  that  encompasses  (he  entire  acquisition  of  a  specific 
defense  materiel  item  shall  be  prepared  by  the  DoD  Component  (Program  Manager).  This  will  be  accomplished 
by  selecting,  through  systems  engineering  and  management  planning  processes,  applicable  elements  from  one  or 
more  of  the  work  breakdown  structnre(s)  specified  in  Appendices  A  through  G.  While  the  categories  and 
elements  specified  in  Appendices  A  through  G  normally  will  prov.de  the  basis  for  constructing  a  program  work 
bicakdown  structure/;.),  deviations  are  permitted  when  a  unique  requirement  exists  which  these  appendices  have 
not  addressed. 

5.2. 1.1  The  preparation  of  the  initial  program  work  breakdown  structure  is  normally  accomplished  by  the  DoD 
Component  as  a  result  of  systems  engineering  efforts  conducted  during  concept  formulation  or  its  equivalent. 
The  initial  program  work  breakdown  structure  shall  be  developed  to  be  available  for  use  as  the  program  moves 
into  demonstration  and  validation  and/or  engineering  and  manufacturing  development.  The  systems  engineering 
effort  identifies  the  category  of  defense  materiel  items  and  work  breakdown  structure  elements  considered  to  be 
most  suitable  to  satisfy  the  operational  needs.  Therefore,  iu  preparing  a  program  work  breakdown  structure  for 
a  specific  defense  materiel  item,  a  selection  of  the  level  2  and  level  3  elements  from  one  or  more  of  the  work 
breakdown  structures  identified  in  Appendices  A  through  G  shall  be  made.  Unless  a  unique  requirement  exists 
which  the  work  breakdown  structures  as  described  by  this  standard  have  not  addressed,  only  the  work 
breakdown  structure  elements  specified  in  this  standard  shall  be  utilized;  and  these  c’cruecis  shall  tie  identified 
with  uniform  uomeiaclature,  definition,  and  strucuiral  placement.  Figure  2,  Program  Work  Breakdown 
Structure,  depicts  a  format  for  developing  and  documenting  a  program  work  breakdown  structure.  Although 
this  structure  is  normally  limited  to  the  upper  three  levels,  additional  elements  at  lower  levels  may  be  specified. 
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5.2. 1 .2  When  deviation  from  the  prescribed  elements  and  definitions  in  this  standard  is  necessary  because  of  a 
unique  requirement,  additional  or  substitute  elements,  properly  defined,  may  be  used  once  DoD  approval 
procedures  have  been  complied  with  and  approval  has  been  obtained. 

5.2. 1.3  The  program  work  breakdown  structure  is  not  intended  to  be  constraining.  During  demonstration  and 
validation  or  subsequent  development  efforts,  changes  may  be  proposed.  Such  alternatives  shall  be  evaluated  by 
the  DoD  Component  in  terms  of  the  benefits  offered  in  context  with  the  overall  program  objectives.  The 
changes  adopted  at  the  end  of  the  demonstration  and  validation  ct  subsequent  effort  shall  be  reflected  in  the 
approved  program  work  breakdown  structure.  The  appropriate  elements  of  the  approved  structure  shall  be 
included  in  the  negotiated  contract  work  breakdown  structure(s)  and  work  statements  for  follow-on  development 
effort. 

5.3  Contract  Work  .Breakdown  Structure. 

5.3.1.  Preparation.  Only  one  contract  work  breakdown  structure  shall  be  used  in  each  request  for  proposal  and 
the  ensuing  contract.  The  DoD  Component  shall  structure  the  upper  levels  of  the  contract  work  breakdown 
structure  by  selecting  those  elements  of  the  program  work  breakdown  structure  which  apply  to  the  contract  and 
organizing  them  into  a  framework  which  supports  the  objectives  of  the  program  work  breakdown  structure. 
Individual  subsyctems/equipment  elements  may  be  extended  to  lower  levels  to  provide  management  visibility  and 
control.  Figure  3.  Work  Breakdown  Structure  Matrix,  depicts  a  format  suitable  for  documenting  the  subdivision 
of  a  program  work  breakdown  structure  into  contract  work  breakdown  structures  for  each  contractor/source.  In 
the  example,  the  program  work  breakdown  structure  level  3  element  Fite  Control  becomes  level  1  of  the 
contract  work  breakdown  structure,  and  all  other  level  2  common  program  work  breakdown  structure  dements 
(ref.  Appendix  H)  arc  included  at  level  2  of  the  contract  work  breakdown  structure.  A  separate  contract  for  a 
level  4  program  work  breakdown  structure  element,  such  as  Aircrew  Training  Device,  also  follows  flic  same 
procedure.  The  same  contract  work  breakdown  structure  drawn  from  die  program  work  breakdown  structure 
shall  be  used  for  each  phase  (development  and  production)  of  a  program.  The  work  breakdown  structure 
element  System  Test  and  Evaluation  is  an  exception  since  it  is  not  used  for  production. 

5.3.2  Relationship  to  Program  Work  Breakdown  Structure.  Work  breakdown  structure  "lever  commonality 
between  the  approved  program  work  breakdown  structure  and  the  individual  contract  vtoik  breakdown  structure 
need  not  be  maintained,  provided  that  the  approved  program  work  breakdo'vn  structure  element  nomenclature 
and  definitions  are  not  violated.  Contract  work  breakdown  structure  levels  may  be  different  from  program  work 
breakdown  structure  levels.  For  example,  level  3  in  die  progra  n  work  breakdown  structure  may  be  level  1  or  2 
in  the  contract  work  breakdown  structure.  In  addition,  not  all  program  work  breakdown  structure  dements  may 
oe  in  each  contract  work  breakdown  structure.  Traceable  summarization  of  individual  contract  work  breakdown 
structures  into  the  approved  program  work  breakdown  structure  shall  be  maintained. 

5.3.3  Changes  to  Contract  Work  Breakdown  S  true,  ares.  When  submitting  and  negotiating  proposals, 
contractors  may  propose  alternative',  to  the  contract  work  breakdown  structure  elements  selected  in  order  to 
enhance  effectiveness  of  the  structure  in  satisfying  the  objectives  of  the  particular  project.  Changes  proposed  by 
the  contractor  shall  require  approval  following  DoD  regulations  and  procedures.  After  necessary  adjustments 
are  made  based  on  a  contractor’s  proposal  and  contract  negotiations,  the  dements  selected  for  the  contract  shall 
become  the  basis  for  further  evolutionary  extension  by  the  contractor  during  the  contracted  effort.  All 
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Figure  3.  WORK  BREAKDOWN  STRUCTURE  MATRIX 
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extensions  must  sum  to  the  contract  work  breakdown  structure  provided  by  the  DoD  Component  and 
documented  in  the  approved  CCDR  Plan. 

5.3.4  Extension  of  Contract  Work  Breakdown  Structure.  The  contract  shall  indicate  the  levels  of  contract  work 
breakdown  structure  at  which  costs  shall  be  reported  to  the  government.  Traceability  of  cost  accumulations 
shall  be  required  to  those  extended  contract  work  breakdown  structure  levels  which  are  used  by  the  contractor 
for  cost  control  purposes. 

5. 3. 4.1  In  the  extended  contract  work  breakdown  structure,  consideration  shall  be  given  to  the  specific 
contractual,  technical,  and  managerial  requirements  of  the  defense  materiel  item.  Lower  levels  may  be 
cotr/tfctrnrtion  items,  service  dements,  items  of  data  or  meamngM  product  or  management  -oriented  lower 
indentures  of  a  higher-level  element.  The  contractor  has  complete  flexibility  in  ewenoing  the  contract  work 
breakdown  structure  below  the  reporting  requirement  to  reflect  how  work  is  to  be  accomplished,  assuming 
lower  elements  to  be  meaningful  product  or  managrment-oriented  lower  indentures  of  a  cipher-level  dement. 
Particular  attention  shall  be  given  to  ensure  the  correlation  of  lower  levels  of  the  contract  work  breakdown 
structure  to  die  specificatum  tree,  contract  line  items,  configuration  items,  data  hems,  and  work  st&sment  tasks. 

5.3.4.2  The  lowest  lcvd  of  the  extended  contract  writ  breakdown  structure  for  project  planning,  control,  and 
support  wdl  be  that  necessary  to  reach  manageable  units  of  functional  tasks  and  ahould  reflect  the  way  the  work 
is  actually  befog  performed  by  the  contractor.  For  configure- ion  management,  the  contract  work  breakdown 
structure  will  be  extended  sufficiently  to  identify  all  configuration  items.  This  standard  does  not  require  that  the 
contract  work  breakdown  structure  level  used  for  program  control  also  be  foe  level  needed  for  configuration 
control. 

5-3.5  Contractually  Specified  Levels.  The  contract  work  breakdown  structure  provided  by  foe  DoD 
Coarponow  {hull  be  attached  to  and  be  a  part  of  foe  solicitation  documents.  The  contra  r!  work  biwrtrfow  * 
structure,  as  negotiated,  shall  be  attached  to  foe  contract.  Information  as  to  the  extended  contract  wort 
breakdown  structure  content  shall  be  available  to  the  government  program  ma-rager  upon  request. 

5.4  Other  Preparation  Guidance. 

5.4.1  General. 

5.4. 1.1  The,  definitions  and  terminology  p resected  fo  foe  appendices  tr  this  standard  shall  be  used  by  foe  DoD 
Component  as  the  basis  for  structuring  the  specific  terminology  and  definitions  for  each  work  breakdown 
structure  element.  The  coEiractor(s)  shall  prepare  specific  definitions  for  the  contract  work  breakdown  structure 
(ref.  6.3). 

5.4. 1.2  Modification  and  changes  such  as  redesign,  rework,  re-engineering,  retooling,  retesting,  and 
refurbishing  shall  be  associated  with  the  work  breakdown  structure  element  identified  in  the  contract  and 
affected  by  the  change. 

5.4. 1.3  The  level  2  program  work  brakdewa  siruetnrc  eletneots  Systems  Fjsgineering  'Program  Management 
and  System  Test  and  Evaluation  are  defined  to  include  any  overall  systems  effort.  These  elements  exclude 
suosystem  or  component  efforts  that  can  be  associated  with  a  haricate/softwarc  clement.  (Far  example, 
acceptance  tests,  qualification  tests,  and  systems  engineering  for  «  particular  bardware/software  component  shall 
be  included  as  part  of  the  effort  associated  with  foe  compoaei-t.  and  not  with  foe  level  2  elements  of  System 
Test  and  Evaluation  and  Systems  Engineering/Program  Management.)  This  does  not  preclude  the  inclusion  of 
an  element  titled  Systems  Engineering /Program  Management  or  System  Test  and  Evaluation  <o  individual 
contract  work  breakdown  strurturc(s)  even  though  tin.  contract  is  for  subsystems  ot  components  of  a  program. 
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In  this  case,  these  efforts  sliall  be  summarized  into  the  subsystem  or  component,  rather  tuzn  the  program  work 
breakdown  structure  level  2  elauems  of  Systems  Eugmecring/Program  Management  and  System  Test  and 
Evaluation. 

5.4.2  Software.  Software  shall  be  accommodated  in  the  appropriate  levels  of  the  work  breakdown  structure. 
Software  shall  be  identified  with  the  lurdware  it  supports. 

5.4.3  Application  to  Other  Than  Major  Fro  crams.  The  work  breakdown  structure  practices  and  procedures 
contained  in  this  standard  may  be  applied  to  other  than  major  programs  as  specified  in  paragraph  1.2.  A 
program  work  breakdown  structure  can  be  developed  for  any  suteysicrrdpiogTdm  regardless  of  size  or 
complexity,  by  proper  application  of  the  product-oriented  structuring  concepts  set  forth  in  this  standard. 

5.4.3. 1  For  example,  given  a  radar  subsystem  within  an  aggregated  program  element  which  is  to  be  managed 
as  a  system  entity,  the  radar  becomes  the  level  1  mission  system,  i.e. ,  radar  system.  Subordinate  to  this  level  1 
radar  system  is  the  level  2  (mission)  radar  equipment  and  required  generic  dements  to  structure  the  subsystem 
as  a  complete  system  entity.  The  level  2  radar  equipment  is  logically  exp  rded  into  level  3  subsystem  elements, 
such  as  transmitter,  receiver,  antenna,  antenna  pedestal,  and  integration,  assembly,  test  and  checkout.  Common 
elements,  such  as  Training,  Peculiar  Support  Equipment,  Data,  and  System  Test  and  Evaluation,  are  identified 
at  level  2  and  extended  to  lower  levels  as  required  for  the  management  and  control  of  all  elements  necessary  to 
meet  the  radar  system  mission  requirements  in  an  operational  environment. 

5.4. 3.2  For  subsystems/programs  involving  two  or  more  contractors,  this  same  technique  is  appro-' ate  for 
applying  a  program  work  breakdown  structure  to  individual  contract  work  breakdown  structures  by 
contractor/source. 

5.4  4  Acquisition  Phase.  The  program  work  breakdown  structure  and  contract  work  breakdown  structuir(s) 
shall  be  established  initially  at  the  award  of  the  development  contract  and  extended  daring  development.  A 
sing>e  program  work  breakdown  structure,  dement  nomenclature,  and  definition  in  accordance  with  the 
guidelines  prescribed  herein  shall  be  maintained  throughout  the  acquisition  phases  to  insure  traceability.  For 
purposes  of  this  standard,  the  acquisition  phase  will  include  all  applicable  contracted  efforts. 

5.4.5  Placement  of  Multi-Function  Equirnnent/Software  in  the  Work  Breakdown  Structure.  Flexibility  is 
required  in  the  systems  engineering  and  design  process,  therefore  latitude  in  placement  of  the  multi-function 
hardware/software  in  die  program  work  breakdown  structure  is  permitted.  This  latitude  will  be  limited, 
however,  by  the  following  principle:  multi -function  hardware/software  will  be  part  of  the  work  breakdown 
structure  element  which  either  includes  the  equipment  in  the  element’s  specification  or  exercises  the  most  critical 
performance  constraint.  (Critical  performance  constraint  is  that  which  primarily  drives  the  design  of  the 
software. )  In  cases  where  the  application  of  this  rule  results  in  a  conflict  in  the  selection  of  the  proper  element, 
the  specification  relationship  ritall  take  precedence. 

5.4.6  Work  Breakdown  Structure  for  Subcontracts.  The  prime  contractor  shall  be  responsible  for  traceable 
summarization:-;  of  subcontractor  data  supporting  its  prime  contract  work  breakdown  structure  elements.  As 
required,  the  prime  contractor  shall  negotiate  a  work  breakdown  structure  with  the  subcontractor  that  permits 
the  prime  contractor  to  fulfill  its  work  statement  and  contract  work  breakdown  structure  requirements,  and 
which  provides  adequate  control  of  the  subcontractor. 
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6,  NOTES 

u.l  Intended  Use,  Tliis  military  standard  is  applicable  to  all  defense  materiel  items  (or  major  modifications)  (a) 
established  as  an  integral  program  element  of  the  Future  Years  Defense  Program  (FYDP),  or  (b)  otherwise 
designated  by  the  DoD  Compoicat  or  the  Under  Secretary  of  Defense  (Acquisition). 

6.2  Quittance  for  Conamctnal  Application.  The  requirements  of  this  standard  may  be  modified  when  deviations 
from  the  prescribed  dements  and  definitions  in  this  standard  are  necessary  because  cf  tmique  requirernessts  (see 
5.2. 1.1.  and  5.2. 1,2.). 

6.3  Dpta  Requirements.  The  following  Data  Item  Description  (DID)  must  be  listed,  as  apptiable,  tm  trie 
Contract  Data  Requirements  List  (DD  Form  1423)  when  this  standard  is  applied  on  a  contract,  in  order  to 
obtain  the  data,  except  where  DoD  FAR  supplement  27.475-1  ewampts  the  requirement  for  s  DD  Form  1423. 

Reference 

Paragraph  DID  Number 

5.4.  l .  l  DI-MGMT-81334  Contract  Work  Breakdown  Stnxtare  and 

Definitions 


Ampliation 

Contract 

Contract  Funds  Status  Report  (CFSR) 

Contract  Work  Breakdown  Structure 
Contractor  Cost  Data  Reporting  (CCDR) 

Cost  Performance  Report  (CPR) 

Cost/Scfaeduie  Control  Systems  Criteria  (C/SCSC) 

Cost/Schedule  Status  Report  (C/SSR) 

Defense  Materiel  Item 

Program  Management 

Program  Work  Breakdown  Structure 

Systems  Bngincaing 

Work  Breakdown  Structure 

6.5  C.hqnpas  fmm  Previous  Issue.  Marginal  notations  are  not  used  in  this  revision  to  identify’  changes  with 
respect  to  the  previous  issue  due  to  the  extensiveness  of  the  changes 
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CONCLUDING  MATERIAL 


Custodians: 

Army  -  Mi 
Navy  -  NM 
Air  Force  -  10 

Review  Activities: 

Army  -  AR,  AT,  AV,  CR,  Ml 
Navy  -  AS,  NW,  MC,  OS,  SH 
Air  Force  -  11.  14,  19,  25,  26,  70,  71,  80,  82,  84 


Preparing  Activity: 
Air  Force  •  30 


(Project  No.  MISC-0051) 
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APPENDIX  A 

WORK  BREAKDOWN  STRUCTURE  AND  DEFINITIONS 
AIRCRAFT  SYSTEMS 


10.  SCOPE 

10.i  This  appendix  provides  the  aircraft  pystem  work  breakdown  structure.  Definitions  for  the  \ircraft  air 
vehicle  arc  provided  in  this  appendix.  Definitions  for  common  WHS  elements  applicable  to  the  ait  craft  and  all 
other  defense  materiel  items  are  in  Appendix  H.  Work  Breakdown  Structure  Definitions,  Common  Elements. 
This  appendix  is  a  mandatory  part  of  the  standard.  The  information  contained  herein  is  intended  for 
compliance. 

20.  APPLICABLE  DOCUMENTS 


20.1 


20.1.1  Specifications.  Standards,  and  Handbooks.  The  following  specifications,  standards,  and  handbooks 
form  a  part  of  this  document  to  the  extent  specified  herein.  Unless  otherwise  specified,  the  issues  of  these 
documents  are  thore  listed  in  the  issue  of  live  Department  of  Defense  Index  of  Specifications  and  Standards 
(DODISS)  and  supplement  thereto,  cited  in  the  solicitation. 


STANDARDS 


MfL-STD-1374  Weigh;  and  Balance  Data  Reporting  Forms  for  Aircraft  (Including 

Roiorcr&ft) 

(Unite;  otherwise  indicated,  copies  of  federal  and  military  specifiuuiou*,  standards,  and  handbooks  are  available 
from  the  Standardization  Documents  Order  Desk,  700  Robbins  Avenue,  Building  #4,  Section  D,  Philadelphia, 
PA  idl  11-5094.) 

20.2  Non-Government  Publications.  This  section  is  not  applicable  to  this  standard. 

30.  WORK  BREAKDOWN  STRUCTURE 


30. 1  Levels.  The  following  is  the  work  breakdown  structure  for  an  aircraft  system. 

Level  1  Level  2  Level  3 

Aircraft  System 

Air  Vehicle 

Airframe 

Propulsion 

Air  Vehicle  Applications  Software 

Ait  Vehicle  System  Software 

Communications/ldentification 

Navigation/Guidance 

Central  Computer 

Fire  Control 

Data  Display  and  Controls 
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Level  1  Level  2  Level  3 

Survivability 
Reconnaissance 
Automatic  Flight  Control 
Central  Integrated  Checkout 
Antisubmarine  Warfare 
Armament 
Weapons  Delivery 
Auxiliary  Equipment 


Systems  Engineering.'PrognaE  Management 


System  Test  and  Evaluation 


Training 


Data 


Peculiar  Support  Equipment 


Common  Support  Equipment 


Operanonal/Site  Activation 


Industrial  Facilities 


Initial  Spares  and  Repair  Pans 


Development  Test  and  Evaluation 
Operational  Test  and  Evaluation 
Mock-ups 

Test  and  Evaluation  Support 
Test  Facilities 


Equipment 

Services 

Facilities 


Technical  Publications 
Engineering  Data 
Management  Data 
Support  Data 
Data  Depository 


Test  and  Measurement  Equipment 
Support  anti  Handling  Equipment 


Test  and  Measurement  Equipment 
Support  and  Handling  Equipment 


System  Assembly,  Installation  and  Checkout 
on  Site 

Contractor  Technical  Support 
Site  Construction 
Site/Ship/Vehiclc  Conversion 


Construction/Con  versiot  i/ Expansion 
Equipment  Acquisition  or  Modernization 
Maintenance  (industrial  Facilities) 
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40.  DEFINITIONS 


40.'.  Aircraft  System.  The  aircraft  system  dement  refers  to  the  complex  of  equipment  (hardware /software), 
data,  services,  anu  facilities  required  to  develop  and  produce  the  capability  of  employing  those  fixed  or  movable 
wing,  rotwy  wing,  cr  compound  wing,  mannedAmroanned  air  vehicles  designed  for  powered  or  unpowered 
(glider)  guided  flight. 

40.1.1  Air  Vehicle.  The  air  vehicle  element  refers  to  the  complete  dying  aircraft,  including  airframe, 
propulsion,  and  all  other  installed  equipment.  It  includes  the  deign,  development,  and  production  of  oongdete 
units  (i.e.,  prototype,  and  operationally  configured  units  which  satisfy  the  requirements  of  their  applicable 
specification(s),  regardless  of  end  use). 


40.1 .1.1  Airframe.  The  airframe  element  refers  to  the  assembled  structural  and  aerodynamic  components  of 
the  air  vehicle  that  support  subsystems  essential  to  designated  million  requirements.  It  includes,  for  example, 
the  basic  structure  (i.e..  wing,  empennage,  fuselage,  and  associated  manual  flight  control  system),  rotary  wing 
pylons,  air  induction  system,  thrust  reverters,  thrust  vector  devices,  starters,  exhausts,  fuel  management  system, 
inlet  control  system,  alighting  gear  (i.e.,  tires,  tubes,  wheels,  brakes,  hydraulics,  etc.),  secondary  power, 
furnishings  (i.e.,  crew,  cargo,  passenger,  troop,  etc.),  instruments  (i.e.,  flight,  navigation,  engine,  etc.), 
environmental  control,  life  support  and  personal  equipment,  racks,  mounts,  intersystem  cables  and  distribution 
boxes,  etc.,  which  are  inherent  to  and  nonsep arable  from  the  assembled  structure,  dynamic  systems  (i.e., 
transmissions,  gear  boxes,  propellers,  if  not  furnished  as  an  integral  part  of  the  propulsion  unit),  rotor  group, 
and  other  equipment  homogeneous  to  the  airframe.  In  addition  to  the  airframe  structure  and  subsystems,  this 
element  includes: 


a.  Integration.  Assembly.  Test  md  Checkout.  Hie  integration,  assembly,  test  and  checkout  element 
indudes  all  efforts  as  identified  in  Appendix  H,  Work  Breakdown  Structure  Definitions,  Common  Elements 
(ref.  page  H-2),  to  provide  the  Uucgrauou,  assembly,  test  sou  checkout  of  all  elements  into  the  urinjoc  to 


form  the  air  vehicle  as  a  whole.  This  includes  all  administrative  and  technical  engineering  labor  to  perform: 
integration  of  level  3  air  vehicle  and  airframe  elements;  development  of  engineering  layouts;  determination  of 
overall  design  characteristics,  and  determination  of  requirements  of  design  review.  It  includes  overall  air 
vehicle  design  and  producibilily  engineering;  detailed  production  design;  acoustic  and  noise  analysis;  loads 
anaiysis;  and  stress  analysis  on  interfacing  airframe  elements  and  all  subsystems;  design  mcmneasitce  effort  and 
development  of  functional  test  procedures.  U  also  includes  coordination  of  engineering  maste  drawings  and 
consultation  with  test  and  manufacturing  groups.  It  includes  tooling  planning,  design,  and  fabrication  of  basic 
and  rate  tools  and  functional  test  equipments,  as  well  as  the  maintenance  of  such  equipment.  It  also  includes 
pt eduction  scheduling  and  expediting;  joining  or  installation  of  structures  such  as  racks,  mounts,  uc.; 
installation  of  seats,  wiring  ducting,  engines,  and  miscellaneous  equipment  and  painting.  Also  included  are  su 
up,  conduct  and  review  of  testing  assembled  components  or  subsystems  prior  to  installation.  This  element  also 
contains  all  effort  associated  with  the-  installation,  integration,  test  and  checkout  of  the  avionic  systems  imo  the 
air  vehicle  including:  design  of  installation  plans;  quality  assurance  planning  and  control  including  material 
inspection;  installation;  recurring  verification  tests;  and  integration  with  nonavionics  airframe  subsystems.  Also 
included  are:  ground  checkout  prior  to  flight  test;  production  acceptance,  testing  and  service  review;  quality 
ass  urance  activities  and  the  cost  of  raw  materials,  purchased  parts,  tod  purchased  equipment  associated  with 
integration  and  assembly. 


b.  Nonrecurring  Avionics  System.  Integration,  The  nonrecurring  avionics  system  integration  element  is 
associated  with  the  individual  avionics  equipment  boxes  and  avionics  software  in  a  functioning  system.  This 
element  includes;  the  labor  required  to  analyze,  design,  and  develop  the  uvionics  suite  interfaces  and  establish 
interface  compatibility  with  non-avionics  support  equipment  sy  stems,  aircraft  systems,  and  mission  planning 
systems;  drawing  preparation  and  establishment  of  avionics  interface  equipment  requirements  and  specifications; 
and  technical  liaison  and  coordination  with  the  military  service,  subcontractors,  associated  contractors,  and  test 
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groups.  Development,  testing,  and  integration  of  software  should  be  included  m  ait  vehicle  applications  and 
system  software,  Has  dement  excludes  avionics  system  testing  (included  tr.  System  lest  and  Evaluation)  and 
aircraft  systems  engineering  effort  (included  in  Systems  Euginoenng/Prograni  Management). 

AU  effort  directly  associated  with  the  remaining  level  3  WBS  elements  is  excluded.  NOTE:  The  structure  and 
equipment  which  comprise  the  airframe  can  be  identified  by  the  use  of  the  weight  tad  balance  reporting  forms 
for  aircraft  (tad'uiirg  rotoruaft)  in  MIL-STD-1374. 

40.1.1.2  Propulsion.  The  propulsion  element  refers  to  that  po  tion  of  the  air  vehicle  that  pertains  to  inst  alled 
equipment  (propulsion  unit  and  other  propulsion)  to  provide  powcr/tftrust  to  propel  the  aircraft  through  all 
phases  of  powered  flight.  This  element  includes  the  engine  as  a  propulsion  unit  within  Itself  (e.g., 
reciprocating,  turbo  with  or  without  afterburner,  or  other  type  propulsion)  suitable  for  integration  with  the 
airframe.  It  also  includes  thrust  rrversers,  thrust  vector  devices,  transmissions,  gear  boxes,  and  engine  control 
units,  if  furnished  as  an  integral  part  of  the  propulsion  unit.  This  dement  also  includes  other  propulsion 
equipment  required  in  addition  to  the  engine  but  not  furnished  as  an  integral  part  of  the  engine,  such  as  booster 
units.  It  also  includes  the  design,  development,  production,  and  assembly  efforts  to  provide  the  propulsion  rant 
as  an  entity.  AU  effort  directly  associated  with  the  elements  and  the  ir.tegialion,  assembly,  test  and  checkout  of 
these  elements  into  the  air  vehicle  is  excluded.  All  ancillary  equipments  that  are  not  an  integral  part  of  the 
engine  required  to  provide  an  operational  primary  powei  source  (i.e.,  air  inlets,  instruments,  controls,  etc.)  are 
excluded. 

40.1.1.3  Air  Vehicle  Applications  Software.  The  air  vehicle  application  software  element  includes  all  the 
software  that  is  specifically  produced  for  the  functional  use  cf  a  computer  system  or  multiplex  data  base  in  the 
air  vehicle.  Ibis  element  refers  to  all  effort  required  to  design,  develop,  integrate,  and  checkout  the  ait  vehicle 
applications  Computer  Software  Configuration  hems  (CSC Is),  sot  including  the  nonsoftware  portion  of  an 
vehicle  firmware  development  and  production  (ref.  ANSI/IEEE  Sid  610.12).  This  element  excludes  software 
that  is  ar.  integral  pan  of  any  specific  subsystem  and  software  that  is  related  to  other  WBS  level  2  dements. 
When  the  opportunity  to  collect  lower  level  information  exists,  the  structure  and  definitions  in  Appendix  Hi, 
Electronic/ Automated  Software  Systems,  will  be  used. 

40. 1 . 1.4  Air  Vehicle  System  Software.  The  air  vehicle  system  software  element  is  defined  ar  software 
designed  for  a  specific  computer  system  or  family  of  computer  systems  to  facilitate  the  operation  and 
maintenance  of  the  computer  system  and  associated  programs  for  the  air  vehicle;  examples  include  operating 
systems  (i.e.,  software  that  controls  the  execution  of  programs),  Compilers  (i.e.,  computer  programs  used  to 
translate  oigber  order  language  programs  into  relocatable  or  absolute  machine  code  equivalents),  and  utilities 
(i.e.,  computer  programs  or  routines  designed  to  perform  general  support  function  required  by  other  application 
software,  by  the  operating  system  or  by  system  users)  (ref.  AN  SI /IEEE.  3td  610.12).  This  element  refers  to  all 
effort  required  to  design,  develop,  integrate  and  checkout  the  air  vehicle  system  software  including  all  software 
developed  to  support  any  air  vehicle  applications  software  development.  It  is  defined  as  air  vehicle  system 
software  required  to  facilitate  'jewdopment,  integration,  cod  maintenance  of  any  air  vehicle  software  build  and 
CSCI.  Tins  excluder  all  software  that  is  mi  integral  p.jt  of  any  specific  subsystem  specification  or  specifically 
designed  an  l  developed  fov  system  test  and  evaluation,  This  element  also  excludes  software  that  is  an  integral 
part  of  any  specific  subsystem,  and  software  that  is  related  to  other  WBS  level  2  elements.  When  the 
opportunity  to  collect  lowei  level  information  exists,  the  structure  and  definitions  iu  Appendix  B, 

Electronic/ Automated  Software  Systems,  will  be  used. 

40.1.1.5  Communications/ldeatifica'on.  The  communications/identification element  refers  to  that  equipment 
(hnrdwaie/software)  installed  in  the  air  vehicle  for  communications  and  identification  purposes.  It  includes,  for 
example,  intercoms,  radio  system(s),  identification  equipment  (IFF),  data  I  nks,  and  control  boxes  associated 
with  the  specific  equipment.  When  an  in'egral  communication,  navigation,  and  identification  package  is  used,  it 
will  be  included  here.  This  item  contains  embedded  software,  that  is,  software  defined  in  the  item  specification 
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ana  provided  by  the  supplier.  When  the  oppe:  tunny  iO  col iuct  lowci  level  informal: on  exists,  the  structure  and 
definition',  in  Appends.  3,  Electronic/ Automated  Software  Systems,  will  be  used.  All  effort  directly  associated 
with  the  remaining  level  3  WSS  elcmr-i  v.'  ,-u-d  the  integration..  ,-sseinbiy,  test  and  checkout  of  these  dements  into 
the  air  vehicle  if  excluded. 

40.1.1.6  Navigation /Gui  iance.  The  ^vigation/guidapee  element  refers  to  that  equipment  (hardware/aoftware) 
installed  in  the  air  vehicle  to  perform  the  navigational  guidance  function.  This  dement  includes,  for  example, 
radar,  radio,  or  other  essential  navigation  equipment,  radar  altimeter,  direction  finding  set,  doppler  compass, 
computer,  and  other  equipment  homogeneous  to  Tie  navigation/ guidance  function  This  item  contains  embedded 
software  ‘hat  is,  software  defined  in  the  item  specification  and  provided  by  the  supplier.  When  the  opportunity 
to  collect  lower  level  information  exists,  the  structure  and  definitions  in  Appendix  B,  electronic/ Aututr^tea 
Software  System.,  will  be  used.  Ail  effort  directly  associated  with  the  remaining  levd  3  WBS  decoct,*  and  the 
integration,  assembly,  test  and  checkout  of  these  dements  into  the  air  vehicle  is  excluded. 

40. 1.1.7  Central  Computer.  The  central  computer  element  refers  to  the  master  data  processing  unfits) 
responsible  for  coordinating  and  directing  the  major  avionic  mission  systems.  This  item  contains  embedded 
software,  th...  is.  software  defined  in  the  itau  specification  an-*  provided  by  arc  supplier.  When  the  opportunity 
to  C'  Sleet  lower  lei  information  exists,  the  .tiucaire  and  diuniuon."  in  Appendix  SB,  Electronic/ Automated 
Software  Systems,  will  be  used.  This  item  specific?’!}  excludes  those  computers  identified  by  individual 
fimetions  listed  in  or  under  othm  levd  3  WET  demrnts.  All  effort  directly  associated  with  the  remaining  level 
3  WBS  elements  and  the  integration,  .iwembiy,  test  and  checkout  of  these  dements  into  the  ah  vehicle  is 
excluded. 

40.1.1.8  Ft.-  Control.  The  fire  control  element  refers  to  that  equipment  (htidware/ software)  installed  in  the 
air  vehicle  which  provides  the  intelligence  necessary  for  weapons  dr  livery  such  as  bombing,  latac/jiny,  and 
firing.  This  e'emen:  includes,  for  example,  redan  and  other  sensors  including  radomes;  apertureu/aniamas,  if 
integral  to  the  fire  control  system,  necessary  for  seated,  target  identification,  rendezvous  and/or  tracking;  self- 
contained  navi  gat,  on  and  air  dan  systems,  dedicated  display;,  scopes,  or  sights;  and  bombing  computer  and 
control  and  safety  devices.  This  item  contains  embedded  software,  ’/hat  is,  software  defined  in  the  item 
specification  and  provided  by  the  supplier.  When  the  opportunity  to  collect  lower  level  information  exists,  the 
structure  and  definitions  in  Appendix  B,  Electronic/ Automated  Software  Systems,  will  be  used.  All  effort 
directly  associated  with  the  remaining  levd  3  WBS  dements  and  the  integration,  assembly,  test  and  checkout  of 
these  elements  into  the  air  vehicle  is  excluded. 

40.1 .1.9  Data  Display  and  Controls.  The  cuu  display  end  controls  element  refers  to  that  equipment 
(hare  ware/ software)  which  provides  visual  presentation  of  processed  data  by  specially  designed  electronic 
devices  through  interconnection  (on  or  off-line)  with  computer  or  component  equipment,  and  associated 
equipment  needed  to  control  the  presentation  of  data.  This  element  provides  the  necessary  flight  and  tactical 
mfonr  a,:on  to  the  crew  for  efficient  management  of  the  aircraft  during  all  segments  of  the  mission  profile  under 
day  and  night  all-weather  conditaoas.  Excluded  are  indicators/ instruments  not  controlled  by  keyboard  via  the 
multiplex  data  bus  and  pinch  md  consoles  which  are  included  under  the  airframe.  It  includes  multi  function 
displays,  control  display  units,  display  processors,  and  on-board  mission  planning  systems.  This  item  contains 
embedded  software,  that  is,  software  defined  in  the  item  specification  and  provided  by  the  supplier.  When  the 
opportunity  to  collect  lower  level  information  exists,  the  structure  and  definitions  in  Appendix  B, 

Electronic/ Automated  Software  Systems,  will  be  used.  All  effort  directly  associated  with  the  remaining  level  3 
WBS  elements  end  the  integration,  assembly,  test  and  checkout  of  these  elements  into  the  air  vehicle  is 
excluded. 

40.1.1.10  Survivability.  The  survivability  dement  refers  to  those  equipments  (hardware/software)  installed  tn, 
or  attached  to,  the  air  vehicle  which  assist  u.  penetration  for  mission  accomplishment.  This  element  includes, 
lor  example,  ferret  aud  search  receivers,  warning  devices  and  other  electronic  devices,  electronic 
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countermeasures,  jamming  transmitters,  chaff,  infra-red  jammers,  terrain-following  radar,  and  other  devices 
typical  of  this  mission  taction.  This  item  contains  embedded  software,  that  is,  software  defined  in  the  item 
specification  and  provided  by  the  supplier.  When  the  opportunity  to  collect  lower  level  information  exists,  tire 
structure  and  definitions  in  Appendix  B,  Electronic/ Automated  Software  Systems,  will  be  used.  All  effort 
directly  associated  with  the  remaining  level  3  WBS  elements  and  the  integration,  assembly,  test  and  checkout  of 
these  elements  into  the  air  vehicle  is  excluded. 

40.1.1.11  Rcconmassanoc,  The  reconnaissance  equipment  element  refers  to  those  equipments 

(hand ware/software)  installed  in,  or  attached  to,  the  air  vehicle  necessary  to  the  reconnaissance!  mission.  This 
element  includes,  for  example,  photographic,  electronic,  infrared,  and  other  sensors;  search  receivers; 
recorders;  warning  devices;  magazines;  and  data  link.  Gun  cameras  are  excluded.  This  item  contains 
embedded  software,  that  is,  software  defined  in  the  item  specification  and  provided  by  the  supplier.  When  the 
opportunity  to  collect  lower  level  information  exists,  the  structure  and  definitions  in  Appendix  B, 

Electronic/ Automated  Software  Systems,  will  be  used.  All  effort  directly  associated  with  the  remaining  level  3 
WBS  elements  and  the  integration,  assembly,  test  and  checkout  of  these  elements  into  the  air  vehicle  is 
excluded. 

40.1.1.12  Automatic  Plight  Control.  The  automatic  flight  control  element  refen  to  electronic  devices  and 
sensors,  which,  in  combination  w;th  the  flight  controls  subsystem  (under  airframe),  enable  the  crew  to  control 
the  flight  path  of  the  aircraft  as  well  as  to  provide  lift,  drag,  aim,  or  conversion  effects.  This  element  includes 
flight  control  computers,  software,  signal  processors,  and  data  transmitting  dementi  that  are  devoted  to 
processing  data  for  either  primary  or  automatic  flight  control  functions.  Electronic  devices  required  for  signal 
processing,  data  formatting,  and  interfacing  between  die  flight  control  elements  are  included,  as  are  the  data 
buses,  optical  links,  and  other  elements  devoted  to  transmitting  flight  control  data.  Flight  control  sensors  such 
as  pressure  transducers,  rate  gyros,  accelerometers,  and  motion  sensors  are  also  included.  Excluded  from  this 
ehannt  are  the  devices  such  as  linkages,  control  surfaces,  and  actuating  device  covered  usdertte  airframe 
WBS  demon.  Also  excluded  are  avionics  devices  and  sensors  rich  as  central  computers,  navigation 
computers,  avionics  data  buses  and  navigation  sensors  which  are  included  under  other  avionics  WBS  elements, 
This  item  contains  embedded  software,  that  is,  software  defined  in  the  item  specification  and  provided  by  die 
supplier.  When  the  opportunity  to  collect  lower  level  information  exists,  the  structure  and  definitions  in 
Appendix  B,  Electronic/ Automated  Software  Systems,  will  be  used.  All  effort  directly  associated  with  the 
remaining  level  3  WBS  elements  and  the  integration,  assembly,  test  and  checkout  of  these  elements  into  the  air 
vehicle  is  exclude  . 

40.1.1.13  Central  Integrated  Checkout  The  central  integrated  checkout  element  refers  to  that  equipment 
(hardware/software)  installed  in  the  air  vehicle  for  malfunction  detection  and  repotting.  This  item  contains 
embedded  software,  that  is,  software  defined  in  the  item  specification  and  provided  by  the  supplier.  When  the 
opportunity  to  collect  lower  level  information  exists,  the  structure  and  definitions  in  Appendix  B, 

Electronic/ Automated  Software  Systems,  will  be  used.  AJ1  effort  directly  associated  with  the  remaining  level  3 
WBS  elements  and  the  integration,  assembly,  test  and  checkout  of  these  elements  into  the  air  vehicle  ts 
excluded. 

40.1.1.14  Anrpmhmarine  Warfare.  The  antisubmarine  warfare  element  refers  to  that  equipment 
(hardware/xo(.  -are)  installed  in  the  air  vehicle  peculiar  to  the  antisubmarine  warfare  mission.  This  dement 
includes,  for  example,  sensois,  computers,  displays,  etc.  This  item  contains  embedded  software,  that  is, 
software  defined  in  the  item  specification  and  provided  by  the  supplier.  When  the  opportunity  to  collect  lower 
level  information  exists,  the  structure  and  definitions  in  Appendix  3,  Electronic/ Automated  Software  Systems, 
will  be  used.  All  effort  directly  associated  with  the  remaining  level  3  WBS  elements  and  the  integration, 
assembly,  test  and  checkout  of  these  elements  into  the  air  vehicle  is  excluded. 
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40.1.1.15  Armament.  The  armament  element  refers  to  that  equipment  (hardware/ software)  installed  in  the  aiT 
vehicle  to  provide  the  firepower  functions.  This  element  includes,  for  example,  guns,  high  energy  weapons, 
mounts,  turrets,  weapon  direction  equipment,  ammunition  feed  and  ejection  mechanisms,  and  gun  cameras. 

This  item  contains  embedded  software,  that  is,  software  defined  in  the  item  specification  and  provided  by  the 
supplier.  When  the  opportunity  to  collect  lower  level  information  exists,  the  structure  and  definitions  in 
Appendix  B,  Electronic/ Automated  Software  Systems,  will  be  used.  All  effort  directly  associated  with  the 
remaining  level  3  WBS  elements  and  the  integration,  assembly,  test  and  checkout  of  these  elements  into  the  air 
vehicle  is  excluded. 

40.1.1.16  Weapons  Delivery.  The  weapons  delivery  element  refers  to  that  equipment  (hardware/software) 
installed  in  the  air  vehicle  to  provide  the  weapons  delivery  capability.  This  element  includes,  for  example, 
launchers,  pods,  bomb  racks,  pylons,  integral  release  mechanisms,  and  other  mechanical  or  electro-mechanical 
equipments  specifically  oriented  to  the  weapons  delivery  function.  This  element  excludes  the 

bombing/ navigation  system  which  is  included  in  the  fire  control  element.  This  item  contains  embedded 
software,  that  is,  software  defined  in  the  item  specification  and  provided  by  the  supplier.  When  the  opportunity 
to  collect  lower  level  information  exists,  the  structure  and  definitions  in  Appendix  B,  Elect ronic^Automaied 
Software  Systems,  will  be  used.  All  effort  directly  associated  with  the  remaining  level  3  WBS  elements  and  the 
integration,  assembly,  test  and  checkout  of  these  elements  into  the  air  vehicle  is  excluded. 

40.1.1.17  Auxiliary  Equipment.  The  auxiliary  equipment  element  refers  to  auxiliary  airframe,  electronics, 
and/or  annsroent/weapons  delivery  equipment  not  allocable  to  individual  element  equipments,  or  which  provide 
tnc  ancillary  functions  to  the  applicable  mission  equipments.  It  includes,  for  example,  auxiliary  airframe 
equipment  such  as  external  fuel  tanks,  pods,  and  rotodomes.  It  also  includes  such  multi-use  equipment  as 
antennas,  control  boxes,  power  supplies,  environmental  control,  racks,  mountings,  etc.  which  are  not 
homogeneous  to  the  prescribed  WBS  elements.  Auxiliary  annaroeni/weapons  delivery  equipment  includes  flares 
and  ejection  mechanisms,  ejector  cartridges,  and  other  items  pcculirx  to  the  mission  function  that  are  not 
identifiable  to  the  armament  or  weapons  delivery  dements  set  forth  in  40.1.1.15  and  40.1.1.16  of  this  qrpendix. 
This  item  contains  embedded  software,  that  is,  software  defined  in  the  item  specification  and  provided  by  the 
supplier.  When  the  opportunity  to  collect  lower  level  information  exists,  the  structure  and  definitions  in 
Appendix  B,  Electronic/ Automated  Software  Systems,  will  be  used  All  effort  directly  associated  with  the 
remaining  level  3  WBS  elements  and  the  integration,  assembly,  test  and  checkout  of  these  elements  into  the  air 
vehicle  is  excluded. 

Definitions  for  common  WBS  elements  applicable  to  the  aircraft  and  all  other  defense  materiel  items  are  ia 
Appendix  H,  Work  Breakdown  Structure  Definitions,  Common  Elements  (ret.  pages  H-l  through  H-10). 
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APPENDIX  B 

WORK  BREAKDOWN  STRUCTURE  AND  DEFINITIONS 
ELECTRONIC/ AUTOMATED  SOFTWARE  SYSTEMS 


10.  SCOPE 

10.1  This  appendix  provides  the  electronic.' automated  software  system  work  breakdown  structure.  Definitions 
for  the  prime  mission  product  (PMP)  and  platform  integration  are  provided  in  this  appendix.  Definitions  for 
common  WBS  elements  applicable  to  the  electronic/ automated  software  system  and  all  other  defense  materiel 
items  are  in  Appendix  H,  Work  Breakdown  Structure  Definitions,  Common  Element*.  This  appendix  is  a 
mandatory  part  of  the  standard.  The  information  contained  herein  is  intended  for  compliance. 

20.  APPLICABLE  DOCUMENTS 

20.1  Government  Documents. 

20.1.1  Specifications.  Standards,  and  Handbooks.  The  following  specifications,  standards,  and  handbooks 
form  a  part  of  this  document  to  the  extent  specified  herein.  Unless  otherwise  specified,  the  issues  of  these 
documents  are  those  listed  in  the  issue  of  the  Department  of  Defense  Index  of  Specifications  and  Standards 
(DODISS)  and  supplement  thereto,  cited  in  the  solicitation. 

STANDARDS 


MIDSTD-196  Joint  Electronics  Type  Designation  System 

MiL-STD-1464  Army  Nomenclature  System 

MIL-STD-1661  Mark  and  Mod  Nomenclature  System 

MIL-STD-1812  Type  Designation,  Assignment  and  Method  for  Obtaining 

DOD-STD-2167  Defense  System  1  itiware  Development 

(Unless  otherwise  indicated,  copies  of  federal  and  military  specifications,  standards,  and  handbooks  are  available 
from  the  Standardization  Documents  Order  Dest,  700  Robbins  Avenue  Building  #4,  Section  D,  Philadelphia, 


PA  19111-5094.) 

20.2  Non-Govemmcr.t  Publications.  This  section  is  not  applicable  to  this  standard . 
30.  WORK  BREAKDOWN  STRUCTURE 


30. 1  Levels.  The  following  is  the  work  breakdown  structure  for  an  elecuonic/automated  software  system.  For 
an)'  subsystem,  specify  by  name  or  nomenclature,  if  assigned. 
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Level  ’  Level  2  Level  3 

Electronic/ Auto maxed  Software  System 

Prime  Mission  Product  (PMP) 

Subsystem  1 . .  .n  (Specify  Names) 

PMP  Applications  Software 

PMP  System  Software 

Integration,  Assembly,  Test  and  Checkout 


Platform  Integration 

Systems  Engineering/Pro gram  Management 


System  Test  and  Evaluation 


Training 


Dam 


Peculiar  Support  Equipment 


Development  Test  and  Evaluation 
Operational  Test  and  Evaluation 
Mock-ups 

Test  and  Evaluation  Suppoit 
Test  Facilities 


Equipment 

Services 

Facilities 


Tecnnical  Publications 
Engine,  ring  Data 
Management  Data 
Support  Data 
Data  Depositoiy 


Test  and  Measurement  Equipment 
Support  and  Handling  Equipment 


Common  Support  Equipment 

Test  and  Measurement  Equipment 
Support  and  Handling  Equipment 

Operalional/Site  Activation 

System  Assembly,  Installation  and  Checkout 
on  Site 

Contractor  Technical  Support 
Site  Construction 
Site/Ship/Vebicle  Conversion 
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Level  1 


Level  2 

Industrial  Facilities 


Initial  Spares  and  Repair  Parts 


LsveLa 


Coiu;tnirAiotiy  Conversion/Expansion 
Equipment  Acquisition  or  Modernization 
Maintenance  (Industrial  Facilities) 
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40.1  Electronic/ Automated  Software  System.  The  r'cctroruc/automated  software  system  clement  refers  to  the 
complex  of  equipment  (hard  ware/so  ft  wre) ,  data,  sc.  ices,  and  facilides  required  to  de  velop  and  produce  an 
electronic,  automated,  or  software,  system  capability  such  as  a  command  and  control  system,  radar  system, 
communications  system,  information  system,  sensor  system,  navigation/guidancc  system,  electronic  warfare 
system,  support  sys»cm,  etc.  The  decision  rule  used  to  differentiate  between  the  Electronic/Automated  Software 
System  category  and  other  defense  materiel  item  categories  is:  When  the  item  is  a  stand  alone  system  or  used 
on  several  systems,  but  not  accounted  for  in  these  other  systems,  the  Electronic/ Automated  Software  System 
category  will  be  used.  When  the  opportunity  to  collect  lower  level  information  on  electronic  and  software  hems 
exists,  regardless  of  which  defense  materiel  item  category  is  selected,  the  structure  and  definitions  in  this 
appendix  apply. 

40.1 .1  Prime  Mission  Product  (PMP).  The  PMP  element  refers  to  the  hardware  and  software  used  to 
accomplish  the  primary  mission  of  the  defense  materiel  item.  It  includes  all  integration,  assembly,  test  and 
checkout,  as  well  as  all  technical  and  management  activities  associated  with  individual  hardware/software 
elements.  Also  included  are  integration,  assembly,  test  and  checkout  associated  with  the  overall  PMP.  When 
the  electronic/automated  software  system  comprises  several  PMPs,  each  will  be  listed  separately  at  level  2. 

Also  included  are  ail  whole  and  partial  prime  contractor,  subcontractor,  and  vendor  breadboards,  brassboards, 
and  qualification  test  units.  It  also  includes  the  design,  development  and  production  of  complete  units  (i.e,,  the 
prototype  or  operationally  configured  units  which  satisfy  the  requirements  of  their  applicable  spedficaJion(s). 
rega  ‘Uess  of  end  use).  It  excludes  only  Uiose  “less  than  whole"  units  (e.g.,  test,  spares,  etc.)  consumed  or 
planned  to  be  consumed  in  support  of  system  level  tests.  This  eiement  also  includes  factory  special  test 
equipment,  special  tooling,  and  production  planning  required  to  fabricate  the  PMP.  Duplicate  or  modified 
factory  special  test  equipment  delivered  to  the  government  for  depot  repair  is  excluded  and  should  be  included 
in  the  peculiar  support  equipment  clement. 

40. 1 .1.1  Subsystem  l...n  (Specify  NamcT).  This  element  refers  to  ait  hardware  and  software  components  of 
the  specific  elcctronic/autnmated  software  subsystem,  including  all  associated  special  test  equipment,  special 
tooling,  production  planning,  and  all  technical  and  management  activities.  The  software  components  consist  of 
the  applications  and  system  software  required  to  direct  and  m-untarn  the  specific.  eiectronrc/automaJed  software 
subsystem.  This  element  includes  all  in-plant  integration,  assembly,  test  and  checkout  of  hardware  components 
and  software  into  an  electronic/auromated  softwa:  e  subsystem  including  the  subsystem  hardware  end  software 
integration  and  lest.  Also  included  are  the  interface  materials  and  parts  required  for  the  in-plant  integration  and 
assembly  of  other  level  4  components  into  the  dectronic/autoroated  software  subsystem  anti  all  materials  and 
pans  ot  other  maiing  equipments  furnished  by /to  an  integrating  agency  or  contractor.  ?t  includes,  for  example, 
cables,  conduits;  connectors,  shelters,  and  other  devices  associated  with  the  operational  electronic. cutomatcu 
software  subsystem.  It  also  includes  the  design,  development,  production,  and  assembly  efforts  to  provide  each 
electronic/autciuated  software  subsystem  as  an  entity ,  All  effort  directly  associated  with  the  remaining  level  3 
WRS  elements  and  the  integration,  assembly,  test  and  checkout  of  these  elements  into  the  PMP  is  excluded. 

40.1.1.2  PMP  Applications  Software.  The  applications  software  element  is  defined  as  software  that  is 
specifically  produced  for  the  functional  use  of  a  computer  system  (ref.  ANSI/IEEE  Std  610.12).  Examples  art 
battle  management,  weapons  control,  and  data  base  management.  This  element  refers  to  all  effort  required  to 
design,  develop,  integrate  and  checkout  the  PMP  applications  computer  software  configuration  items  (CSCls), 
no:  including  the  nonsofiware  portion  of  PMP  firmware  development  and  production.  This  excludes  all 
software  that  is  an  integral  par  of  any  specific  hardware  subsystem  specification. 

All  software  that  is  an  Integra1  part  of  any  specific  equipment  system  and  subsystem  specification  or  specifically 
designed  and  developed  for  system  test  and  evaluation  should  be  identified  vvitl;  that  system,  subsystem,  or 
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effort.  It  nay  be  appropriate  to  collect  lower  level  information  when  it  exiBts.  in  such  cases,  the  following 
structure  and  definitions  should  be  used: 

LEVEL  4  LEVEL  5 

Build  1  ..n  (Specify  Names)  CSC1  l...n  (Specify  Names) 

CSCI  to  CSC1  Integration  and  Checkout 

Integration,  Assembly,  Test 

and  Checkout 

a.  Build  l...n  (Specify  Names)  -  A  software  build  is  an  aggregate  of  one  or  more  CSCls  that  satisfies 
a  specific  set  or  subset  of  requirements  based  on  development  of  software  as  defined  in  DOD-STD-2167A. 

When  incremental,  spiral,  or  other  software  development  method  is  used,  multiple  builds  may  be  necessary  to 
meet  program  requirements.  A  build  is  a  separately  tested  and  delivered  product.  Within  builds  ate  CSCls. 
When  a  build  is  complete,  a  portion  or  all  of  one  or  more  CSCls  will  be  completed.  Therefore,  a  CSCI  may 
appear  in  more  than  one  build,  but  will  be  successively  more  functional  as  each  build  is  completed. 

b  Computer  Software  Configuration  Item  (CSCI)  J .  j  (Specify  Nam«)  -  An  aggregation  of  software 
or  any  of  its  discrete  portions  which  satisfies  an  end  use  function  and  has  been  designated  by  the  government  for 
configuration  management.  CSCls  are  the  major  software  products  of  a  system  acquisition  which  are  developed 
in  accordance  with  DOD-STD-2167.  This  includes  reusable  software  components,  such  as  commercial  off-the- 
shelf  software,  government  furnished  software,  or  software  specifically  developed  for  reuse.  This  dement 
includes  Computer  Software  Camponwitt  (CSCs)  which  are  functionally  or  logically  a  distinct  part  of  a  CSCt, 
distinguished  for  convenience  in  designing  and  specifying  a  complex  CSCI  as  an  assembly  of  subordinate 
dements,  It  includes  the  effort  associated  with  the  requirements  analysis,  design  coding  ana  resting.  CSCs 
integration  and  testing,  CSCI  formal  qualification  testing,  and  software  problem  resolution  of  each  CSCI. 

c.  CSCI  to  CSCI  Integration  and  Checkout  -  Includes  integration  and  test,  verification  and  validation 
and  the  systems  engineering  and  technical  control  of  the  CSCIc.  Integration  and  test  is  the  planning,  conducting 
and  analysis  of  tests  that  verify  correct  and  proper  performance  of  each  CSCI  operating  as  a  whole  with  other 
CSCls.  Planning  includes:  (1)  defining  test  scope  and  objectives,  (2)  establishing  the  test  approach,  acceptance 
criteria,  verification  methods,  order  c(  integration,  inputs,  and  methods  io  record  results,  and  (3)  establishing 
test  locations,  schedules,  and  responsibilities  of  those  involved.  The  conducting  and  analysis  of  tests 
encompasses:  (l)  developing  test  procedures,  (2)  preparing  test  data  and  expected  results,  (3)  executing  the  test 
procedures  and  recording  test  results,  (4)  reducing  test  results, identifying  errors,  and  preparing  test  data  sheets, 
and  (5)  reporting  results.  Verification  and  validation  is  the  effort  that  may  be  accomplished  to  insure  the 
performance  and  quality  of  each  CSC*  with  other  CSCls.  This  clement  excludes  the  software  integration  and 
checkout  associated  with  the  individual  CSCls. 

(NOTE:  The  defined  software  structure  for  lower  level  information  is  appropriate  whether  it  is  associated  with  a 
specific  system  or  subsystem  or  considered  software  intensive  or  stand  alone.  Reference  Appendix  I,  User 
Guide,  for  guidelines  on  developing  a  stand  alone  software  work  breakdown  structure.) 

40.1.1.3  FMP  Svs’em  Software.  The  PMP  system  software  element  is  defined  as  software  designed  for  a 
specific  computer  system  or  family  of  computer  systems  tc  facilitate  the  operation  and  maintenance  of  the 
computer  system  and  associated  programs,  for  example,  operating  systems,  compilers,  and  utilities  (ref. 
ANSI/IEEE  Std  610.12).  This  element  refers  to  ail  effort  required  to  design,  develop,  integrate  and  checkout 
the  PMP  system  software  including  all  software  developed  to  support  any  PMP  applications  software 
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development,  It  is  defined  as  PMP  system  software  which  is  requited  to  facilitate  development,  integration,  and 
maintenance  of  any  PMP  software  build  and  CSCI.  This  excludes  il  software  that  is  an  integral  part  of  any 
specific  hardware  subsystem  specification  or  is  specifically  designed  and  developed  for  system  tea!  and 
evaluation.  The  structure  shown  in  paragraph  40.1.1.2  should  be  used  when  lower  level  information  is  desired. 

40.1.1.4  Integration.  Assembly,  Test  and  Checkout.  The  integration,  assembly,  test,  and  checkout  element 
includes  all  effort  ss  identified  in  Appendix  H,  Work  Breakdown  Structure  Definitions,  Crnmnn  Bjanemta  (ref. 
page  H-2)  to  provide  a  complete  PMP  system.  The  rategraikm,  assembly,  test  and  checkout  element  includes 
hardware  and  PMP  software  integration  and  test. 

40.1.2  Platform  Integration.  The  platform  integration  element  refers  to  all  effort  involved  in  providing 
technical  and  engineering  servi'tes  to  the  platform  manufacturer  or  integrator  during  the  installation  and 
integration  of  the  PMP  into  the  host  vehicle.  This  element  includes:  the  labor  required  to  analyze;  design,  and 
develop  the  interfaces  with  other  host  vehicle  subsystems;  drawing  preparation  and  establishment  of  ncpupmern 
requirements  tad  specifications;  sod  technical  Utdaou  and  coordination  with  the  military  servers, 
subcontractors,  associated  contractors,  and  test  groups.  Specifically  excluded  from  this  element  is  all  integration 
effort  not  directly  associated  with  the  host  vehicle  and  management  liaison  with  the  military  services, 
subcontracto-s,  ».-d  associated  contractors. 

Definitions  for  common  WBS  elements  applicable  to  the  electronidautomated  software  system  and  all  other 
defense  materiel  items  are  a  Appendix  H,  Work  Breakdown  Structure  Definitions,  Common  Elements  (ref. 
pages  H-l  through  H-iO) 
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APPENDIX  C 

WORK  BREAKDOWN  STRUCTURE  AND  DEFINITIONS 
MISSILE  SYSTEMS 


10.  SCOPE 

10.1  This  appendix  provides  the  missile  system  work  breakdown  structure.  Definitions  for  the  missile  air 
vehicle  and  command  and  launch  equipment  arc  provided  in  this  appendix.  Definitions  for  common  WBS 
elements  applicable  to  the  missile  and  all  other  defense  materiel  items  are  in  Appendix  H,  Work  Breakdown 
Structure  Definitions,  Common  Elements  This  appendix,  is  a  mandatory  pan  of  the  standard.  The  information 
contained  herein  is  intended  for  compliance. 

20.  APPLICABLE  DOCUMENTS 

This  section  is  not  applicable  to  this  appendix. 

30.  WORK  BREAKDOWN  STRUCTURE 

30.1  Levels.  The  following  is  the  work  breakdown  structure  for  a  missile  system. 

Level  1  Level  2  I-evd  3 


Missile  System 


Air  Vehicle 


Propulsion  (Stages  i...n.  As  Required) 

Payload 

Airframe 

Reentry  System 

Pos.  Boost  System 

Guidance  and  Control 

Ordnance  Initiation  Set 

Airborne  Test  Equipment 

Airborne  Training  Equipment 

Auxiliary  Equipment 

Integration,  Assembly,  Test  and  Checkout 


Command  and  Launch 

Surveillance,  Identification  and  Tracking  Sensors 
Launch  and  Guidance  Control 
Communications 

Command  and  launch  Applications  Software 
Command  and  Launch  System  Software 
Launcher  Equipment 
Auxiliary  Equipment 


Systems  Engineering/Program  Management 
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svel  2 


Syswm  Test  and  Evaluation 


Training 


Dih 


Peculiar  Support  Equipment 


Common  Support  Equipment 


Operational/Site  Activation 


Industrial  Facilities 


Initial  Spares  and  Repair  Parts 


LSSLl 


Development  Test  and  Evaluation 
Operational  Test  and  Evaluation 
Mock-ups 

Test  and  Evaluation  Support 
Test  Facilities 


Equipment 

Services 

Facilities 


Technical  Publications 
Engineering  Data 
Management  Data 
Support  Dal* 

Data  Depository 


Test  arid  Measurement  Equipment 
Support  and  Handling  Equipment 


Test  sed  Measurement  Equipment 
Support  and  Handling  Equipment 


System  Assembly,  Installation  and  Checkout 
on  Site 

Contractor  Technical  Support 
Site  Construction 
Site  Conversion 


Construction/Conversion/Expansion 
Equipment  Acquisition  or  Modernization 
Maintenance  (Industrial  Facilities) 
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40.  DEFINITIONS 

40. 1  Missile  System,  The  missile  system  element  refen  to  the  complex  of  equipment  (hardware/ software) 
data,  services,  and  facilities  required  to  develop  and  produce  the  capability  of  employing  a  missile  weapon  in  an 
operational  environment  to  produce  the  destructive  effect  on  selected  targets,  examples  include  Trident, 
Peacekeeper,  Tomahawk,  Maverick,  Sidewinder,  etc. 

40.1.1  Air  Vehicle,  The  air  vehicle  element  refer*  to  tue.  primary  means  for  dehvenng  the  destructive  effect  to 
the  trrgct,  including  the  capability  to  generate  or  receive  intelligence,  to  navigate  and  peuetnue  to  the  target  area 
and  to  detonate  the  wrriicad.  It  also  includes  the  design,  development,  and  production  of  complete  emits  (i.e„ 
the  prototype  or  operationally  configured  units  which  satisfy  the  requirements  of  tneir  applicable  specification(s), 
regardless  of  aid  rse). 

40. 1 . 1 . 1  Propulsion  (Stages  I...n.  As  Required).  The  propulsion  system  provides  the  thrust  to  propel  tbs  air 
v chide  on  its  intended  flight.  The  propulsion  system  may  be  oomposod  of  one  or  more  which  ignite, 
bum,  and  arc  jettisoned  sequentially  over  the  comae  of  missile  flight.  The  propulsion  dement  mav  be  solid, 
liquid,  or  air-breathing,  it  includes,  for  example,  structure  (integral  to  the  propulsion  system),  propelleui, 
controls,  instrumentation .  and  all  other  installed  subsystem  equipment  integral  to  the  rocket  motor  or  engine  as 
an  entity  within  itself.  It  also  includes  the  design,  development,  production,  and  assembly  efforts  to  provide 
each  stage  as  an  entity.  All  effor*  directly  associated  with  the  remaining  level  3  WBS  elements  and  the 
integration,  assembly,  test  and  checkout  of  these  elements  into  the  air  vehicle  is  excluded. 

a.  Rocket  Motor/Booster  A  rocket  motor/booster  refers  to  the  solid  propulsion  system  which  carries 
within  it  both  the  fuel  and  oxygen  required  for  its  operation.  It  includes,  for  example,  an  arm  and  firing  device, 
solid  propellant,  movable  nozzles,  casings,  integration,  etc. 

gikiaf.  Tiie  eajUue  include*  noth  iiqmd  propulsion  systems  and  air  breathing  systems.  The  liquid 
propulsion  engine  includes,  for  example,  the  main  engines,  verniers/ auxiliary'  engines,  fluid  supply  system, 
liquid  propellant,  attitude  control  equipment,  structure  (integral  to  the  engine),  raceway,  interstage,  combustion 
section,  turbines,  nozzles,  rotors,  etc.  The  air  breathing  engine  obtains  oxygen  from  the  surrounding 
atmosphere  to  support  the  combustion  of  its  fuel.  Ramjets  aud  turbojets  are  examples  of  air  hrcathing  mvinrt 
which  may  be  used  to  provide  propulsion  for  cruise-type  missiles.  This  element  includes  the  following 
subsystems  for  air  brcathmg  engines:  mainframe,  compressor,  combustion  section,  air  inlets 'exhaust  ducts, 
turbine  nozzle  assembly,  turbine  rotor,  bearings  and  housings,  and  fuel  subsystem.  In  addition  to  basic 
components,  air  breathing  engine  systems  require  various  accessory  component*  such  as  pumps,  injectors, 
turbines,  motors,  diffusers,  and  igniters. 

40.1.1.2  Payload.  The  payload  element  refers  to  the  subsystem  containing  the  warhead  and  its  support 
assemblies  where  no  reentry  system  exists.  Normally,  payload  consists  only  of  the  warhead  and  its  associated 
arming  and  fuzing  equipment.  However,  with  complex  munitions  containing  submunitions.  the  payload 
subsystem  may  mimic  the  larger  system  by  having  its  own  guidance  and  control,  fuze,  safe-arm,  and 
propulsion.  This  element  includes,  for  example,  arming  and  fuzing  device,  warhead,  and  target  detection 
device.  All  effort  directly  associKed  with  the  remaining  level  3  WBS  (dements  and  the  integration,  assembly, 
test  aud  checkout  of  these  elements  into  the  ah  vehicle  is  excluded. 

40  1.1.3  Airframe.  The  airframe  elemeut  includes  the  structural  framework  that  provides  the  aerodynamic 
shape,  mounting  surfaces  and  environmental  protection  for  the  missile  components  which  are  not  directly 
applicable  to  other  specific  level  3  air  vehicle  subsystems.  The  airframe  for  eado-atmospheric  missiles  normally 
includes  such  items  as  wings  and  fins  which  provide  aerodynamic  flight  control  in  response  to  electro¬ 
mechanical  signals  and  are  attached  to  tne  missile  bouy;  and  structural  body  assemblies  including  the  structure, 
covers,  such  as  passive  noscpicces,  skins,  adhesive;,  and  failings  not  directly  applicable  to  any  other  level  3  air 
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vehicle  subsystem.  All  effon  directly  associated  with  the  remaining  level  3  WBS  elements  and  the  integration, 
assembly,  rest  and  checkout  of  these  elements  into  the  air  vehicle  ts  excluded. 


40.1.1.4  Reentry  System.  For  exo-atmospheric  missiles,  the  reentry  system  is  the  aggregate  of  prime 
equipment  items  consisting  of  a  deployment  module,  reentry  vehicles,  payload,  penetration  aids  and  ascent 
shroud,  which  provide  structural  support  and  environmental  protection  of  nuclear  payloads  during  the  ground 
deployment  and  flight.  The  reentry  vehicle  is  the  aero- structure  which  provides  reentry  protection  for  the 
internally  carried  warheads  and  the  arming  snd  fusing  system  which  provides  the  proper  eiecmcsl  signals  to 
detonate  die  warhead.  Where  the  system  has  the  capability  for  independent  maneuvers,  the  reentry  vehicle  will 
contain  navigation,  guidance,  control,  sensors,  and  processing  systems  which  provide  the  reentry  systems 
capability  to  acquire  »od  crack  targets  and  execute  the  necessary  flight  path  to  the  selected  target.  All  effort 
directly  associated  with  the  remaining  level  3  WBS  elements  and  the  integration,  assembly,  test  and  checkout  of 
these  elements  into  the  air  vehicle  is  excluded. 


40.1.1.5  Post  Boom  System.  In  exo-atmospheric  missiles,  the  post  boost  system  provides  th,'-  toll  rale  control 
and  the  final  velocity  to  adjust  and  deploy  the  payload.  For  a  single  warhead  missile,  this  element  includes  the 
structure,  external  protection  material,  velocity  control  system,  and  deployment  group.  In  the  case  of  the 
multiple  warhead  missile,  the  element  includes  structure,  axial  engines,  attitude  control  equipment,  prcrpellaat 
storage  assembly,  ami  pressurized  system.  All  effort  directly  associated  with  the  remaining  level  3  WBS 
elements  and  the  mtegnu'ion.  assembly,  test  and  checkout  of  these  elements  into  the  air  vehicle  is  excluded. 

40.1.1.6  Guidance  and  Control.  The  guidance  and  control  element  refers  to  the  equip  mm!  used  to  control  the 
missile  flight  to  the  target.  Functions  include  acquiring  and  tracking  targets,  receiving  guidance  intelligence 
data  from  various  sources  including  sensors  and  lerdback  from  control  commands  to  follow  the  necessary  flight 
path  to  intercept  the  target.  The  inputs  may  also  include  interlace  status,  menial  acuderation,  and  ertitwie 
changes.  The  outputs  include  missile  control,  ordnauce  tiring  commands,  status,  instrumentation,  and  timing 
signals.  Is  addition,  the  equipment  provides  Sight  electrical  power,  missile  cHiunau  interconnection,  and  a 
structure  to  contain  the  guidance  and  control  components  when  the  structure  is  not  part  of  a  separately  identified 
airframe  element.  For  exo-atraospheric  missiles,  this  includes  missile  cables,  stage  cables,  stage  connectors, 
airborne  power  supply,  electronic  battery,  ordnance  battery,  ordnance  initiation  set.  missile  electronic  and 
computer  assembly,  inertial  measurement  unit,  the  guidance  and  control  softw."’-'1,  it'  flight  coolant  assembly, 
and  guidance  and  control  integration,  assembly,  test  and  checkout.  For  endo  atmospheric  missiles,  thh>  includes 
seekers,  mission  computer,  global  positioning  receiver,  inertial  platform,  inertial  sensors,  altimeter,  data  link, 
power  subsystems,  windows/domes,  distributive  systems,  autopsiot,  flight  control  actuators,  guidxnce  and 
control  software,  and  guidance  and  control  integration,  assembly,  test  and  checkout.  All  effort  directly 
associated  with  the  remaining  level  3  WBS  elements  and  the  integration,  assembly,  test  and  checkout  of  these 
elements  into  the  air  vehicle  is  excluded. 


40.1.1.7  Ordnance  initiation  Set.  In  cxo-atoK spheric  missiles,  the  ordnance  initiation  set  initiates  all  ordnance 
events  throughout  the  missile  and  ground  system  (except  reentry  system  componen's).  Upon  receipt  of  an 
electrical  s’gral  from  the  missile  guidance  and  control  xys nan,  the  ordnance  initiation  set  firing  unit]  convert  the 
signal  mto  ordnance  outputs  to  the  detonating  amis.  Among  those  ordnance  events  are:  stage  separation, 
motor  ignition,  gas  generator  ignition,  shroud  separation,  etc.  This  element  includes  the  through  bulkhead 
initiators,  ordnance  test  harnesses,  and  firing  units/exploding  bridgewirts.  All  effort  directly  associated  with  the 
remaining  level  3  WBS  elements  and  the  integration,  assembly,  test  and  checkout  of  these  elements  into  the  an 
vehicle  u  excluded. 


40. 1.1.8  Airpome  Test  Euuinment.  The  airborne  t.rst  equipment  element  refers  to  an  instrumented  payload  that 
is  interchangeable  with  the  live  warhead  and  suitable  for  developmental  test  firing.  This  element  includes,  for 
example,  recovery  systems,  special  instrumentation,  telemetry  equipment,  etc.  All  effon  directly  associated 
with  the  remaining  level  3  WBS  elements  and  the  integration,  assembly,  test  and  checkout  of  these  elements  into 
the  air  vehicle  is  excluded. 
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40.1.1.9  Airborne  Training  Equipment.  The  airborne  training  equipment  element  refers  to  an  exercise  pay  load 
that  is  interchangeable  with  the  live  warhead  and  suitable  for  training  firing.  This  element  includes,  for 
example,  recovery  systems,  special  instrumentation,  telemetry  equipment,  etc.,  associated  with  the  training 
mission.  All  effort  directly  associated  with  the  remaining  level  3  WB5  elements  and  the  integration,  assembly, 
test  and  checkout  of  these  elements  into  the  air  vehicle  is  excluded. 

40.1.1.10  Auxiliary  Equipment,  The  anxiliaiy  equipment  demon  refers  to  that  additional  equipment  generally 
excluded  from  other  specific  level  3  elements.  This  dement  indudes,  for  example,  environmental  control, 
safety  and  protective  subsystems,  destruct  systems,  etc.,  if  these  were  not  accounted  for  in  other  WBS  dements. 
It  also  includes  equipment  of  a  single  purpose  and  function  which  is  necessary  for  accomplishing  the  assigned 
mission.  All  effort  directly  associated  with  the  remaining  level  3  WBS  dements  and  the  integration,  assembly, 
test  and  checkout  of  these  elements  into  the  air  vehicle  is  exduded. 

40.1.1.11  Integration.  Assembly.  Test  and  Checkout.  The  integration,  assembly,  test  and  checkout  dement 
indudes  all  efforts  as  identified  in  Appendix  H,  Work  Breakdown  Structure  Definitions,  Common  Elements 
(ref,  page  H-2),  to  provide  a  complete  missile. 

40.1.2  Command  and  Launch.  The  command  and  launch  element  refers  to  the  subsystems  installed  at  a  launch 
site  or  aboard  launch  vehicles  required  to  store,  make  ready,  and  launch  the  air  vehides  of  the  missile  system. 
This  element  indudes  those  equipments  required  to  acquire  and  condition  the  necessary  intelligence  of  selected 
targets,  reach  launch  decisions,  command  the  launch,  and  provide  guidance  and  control  where  such  capability  is 
not  self  contained  aboard  the  air  vehicle  It  also  includes  the  design,  development  and  production  of  complete 
units  (i.e.,  the  prototype  or  operationally  configured  units  which  satisfy  the  requirements  of  their  applicable 
specification(s),  regardless  of  end  use). 

40.1.2.1  Surveillance.  Identification  and  Tracking  Sensors.  The  surveillance  itkiaificsioG,  and  tracking 
sensors  element  refers  to  those  sensors  required  to  support  missile  systems  by  maintaining  surveillance  against 
incoming  targets  and  providing  die  data  required  for  targeting,  launch,  midcourse  guidance  and  homing  where 
such  capability  is  not  self-contained  aboard  a  missile  system  air  vehicle.  For  all  classes  of  missile  systems,  they 
may  include  tracking  of  the  missile  system  air  vehicles  as  required  for  guidance  and  control  or  range  safety. 
Subsystems  used  in  safety,  destruct.  test,  or  training  activities  are  not  included  unless  they  are  required 
operational  items.  This  dement  may  include,  for  example,  sensors  of  any  spectrum  (radar,  optical,  infrared, 
etc.)  which  are  external  to  the  air  vehicle. 

40.1.2.2  Launch  and  Guidance  Control.  The  launch  and  guidance  control  dement  refers  to  the  equipment  to 
target  air  vehicles,  make  launch  decisions,  and  command  launch.  This  indudes  such  items  as  the  control  and 
checkout  console,  data  displays,  secure  code  device,  programmer  group,  communication  control  console, 
command  message  processing  group,  and  digital  data  group.  It  also  indudes  equipment  at  the  laundi 
facility/vehicle  and/or  the  launch  control  center(s)  (air,  sea,  or  mobile).  It  also  includes  the  launch  code 
processing  system. 

4Q.  1.2.3  Communications.  The  communications  element  refers  to  the  equipment,  not  resident  on  the  air 
vehicle,  which  distributes  intelligence  between  the  air  vehicle  and  the  command  and  launch  equipment.  This 
element  indudes  inter-communication  subsystems  of  launch  sites  for  tactical  and  administrative  message  flow 
and  ties  between  sensor,  data  processing,  launch,  and  guidance  control  subsystems.  Communications  may 
interface  with  existing  fixed  communication  facilities  or  communication  subsystems  of  launch  platforms  which 
are  associated  systems  to  the  missile  system. 

40.1.2.4  Command  and  Launch  Applications  Software.  The  command  and  launch  applications  software 
element  includes  all  the  software  required  to  direct  and  perform  the  operations  of  the  command  and  launch 
equipment  (ref,  ANSI/IEEE  Std  610.12).  This  element  refers  to  all  effort  required  to  design,  develop, 
integrate,  and  checkout  the  command  and  launch  applications  computer  software  configuration  items  (CSCIs), 
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not  ircluding  the  nonsoftwarc  portion  of  command  and  launch  firmware  development  and  production.  When  the 
opportunity  to- collect  lower  level  information  exists,  the  structure  aod  definitions  in  Appendix  B, 

Electronic/ Automated  Software  Systems,  will  be  used. 

40.1.2.5  Command  and  Launch  System  Software.  The  command  and  launch  system  software  element  is 
defined  as  software  designed  for  a  specific  computer  system  or  family  of  computer  systems  to  facilitate  the 
operation  and  maintenance  of  the  computer  system  and  associated  programs,  fix  example,  operating  systems, 
compilers, -and  utilities  (ref.  ANSI/IEEE  Std  610,12).  This  element  refen  to  all  effort  requited  to  design, 
develop,  integrate  and  checkout  the  command  and  launch  system  software  including  all  software  developed  to 
support  any  command  and  launch  applications  software  development.  It  is  defined  es  command  and  launch 
system' software  which -is  required  to  facilitate  development,  integration,  and  maintenance  of  aay  notnmaad  and 
launch  software  CSCI.  This  excludes  all  software  that  is  an  integral  part  of  any  specific  hardware  subsystem 
specification  or  specifically  designed  and  developed  for  system  test  and  evaluation.  When  the  opportunity  to 
collect  lower  level  information  exists,  the  structure  and  definitions  in  Appendix  B,  Electronic/ Automated 
Software  Systems,  will  be  ared. 

40.1.2.6  Launcher  Equipment.  The  launcher  equipment  element  refers  to  the  means  to  launch  Use  missile  air 
vehicle  from  stationary  sites  or  mobile  launch  platforms.  It  includes  vehicles,  tail  launchers,  canisters, 
capsules,  tubes,  pods  and  devices  which  support,  suspend  or  encase  the  air  vehicle  for  firing.  It  also  includes 
associated  hardware  such  as  umbilicals,  harnesses,  pyrotechnics,  and  electronics.  This  element  may  include 
storage  facilities  and  checkout  stations  for  readiness  verification  wher  these  are  integral  to  the  launcher.  It  may 
include  safety  and  protective  elements  when  these  are  not  integral  to  the  launch  platform  or  site  facilities. 

40. 1.2.7  Auxiliary  Equipment.  The  auxiliary  equipment  element  refers  to  the  general  purpose/ multi-usage 
ground  equipment  utilized  to  support  the  various  operational  capabilities  of  the  command  and  launch  equipments 
and  ate  generally  excluded  from  other  specific  level  3  elements.  This  element  includes,  for  example,  power 
generators,  power  distribution  systems,  mviromuentai  control,  cabling,  malfunction  detection .  fire  prevention, 
security  systems,  and  other  common-usage  items  not  applicable  to  specific  clcuwais  of  the  ground  baaed 
equipment. 

Definitions  for  common  WBS  elements  applicable  to  the  missile  and  all  other  defense  materiel  items  are  in 
Appendix  H,  Work  Breakdown  Structure  Definitions.  Common  Elements  (ref.  pages  H-l  through  H  10). 
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APPENDIX  D 

WORK  BREAKDOWN  STRUCTURE  AND  DEFINITIONS 
ORDNANCE  SYSTEMS 


10.  SCOPE 

10.1  This  appendix  provides  the  ordnance  system  work  breakdown  structure.  Definitions  for  the  complete 
round  and  launch  system  ate  provided  in  this  appendix.  Definitions  for  common  WBS  elements  applicable  to 
the  ordnance  system  and  all  other  defense  materiel  items  are  in  Appendix  H,  Work  Breakdown  Structure 
Definitions,  Common  Elements  This  appendix  is  a  mandatory  part  of  the  standard.  The  information  contained 
herein  is  intended  for  compliance. 

20.  APPLICABLE  DOCUMENTS. 

This  section  is  not  applicable  to  this  appendix. 

30.  WORK  BREAKDOWN  STRUCTURE 

30.1  Levels.  The  following  is  the  work  breakdown  structure  for  an  ordnance  system. 

Level  1  Level  2  Level  3 

Ordnance  System 

Complete  Round 

Structure 

Payload 

Guidance  and  Control 
Fuze 

Safety/Ann 

Propulsion 

Integration,  Assembly,  Test  and  Checkout 

l  aunch  System 

Launcher 
Carriage 
Fire  Control 
Ready  Magazine 
Adapter  Kits 

Integration,  Assembly ,  Test  and  Checkout 


Systems  Engineering  /Program  Management 
System  Test  and  Evaluation 

Development  Test  and  Evaluation 
Operational  Test  and  Evaluation 
Mock-ups 

Test  and  Evaluation  Support 
Test  Facilities 


Level  1 


Lesu 

Training 


MIL-STD-881B 


Data 


Peculiar  Support  Equipment 


Common  Support  Equipment 


Operational/Sitc  Activation 


Industrial  Facilities 


Initial  Spares  and  Repair  Parts 


Level  3 


Equipment 

Services 

Facilities 


Technical  Publications 
Engineering  Data 
Management  Data 
Support  Data 
Data  Depository 


Test  and  Measurement  Equipment 
Support  and  Handling  Equipment 


Test  and  Measurement  Equipment 
Support  and  Handling  Equipment 


System  Assembly,  Installation  and  Checkout 
an  Site 

Contractor  Technical  Support 
Site  Construction 
Site  Conversion 


Construction/Conversion/Expansion 

Equipment  Acquisition  or  Modernization 
Maintenance  (Industrial  Facilities) 
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40,  DEFINITIONS 

40. 1  Ordnance  System.  The  ordnance  system  dement  refers  to  the  complex  of  equipment  (hardware/ software), 
dau,  services,  and  facilities  required  to  develop  and  produce  the  capability  for  applying  munition*  to  a  tuget. 

It  indkdes  the  munitions  (nuclear,  biological,  chemical,  psychological,  and  pyrotechnic)  aid  the  of 
launching  or  firing  the  munitions,  and  is  represented  by  MK48  torpedo  system,  SNAKEYE  bomb,  Combined 
Effects  Munitions,  GATOR,  Sensor  Fuzed  Weapon,  8 -inch  Howitzer,  and  .223  caliber  ammunition  Excludeq 
are  aerospace  guided  muaiks  and  land,  sec,  or  air  delivery  vehicles. 

40. 1 . 1  Complete  Round.  The  complete  round  element  refen  to  all  the  components  that  are  necessary  for  firing 
one  shot,  such  as  mines  bombs,  rockets,  torpedoes,  naval  guns,  rifles,  and  artillery  ammunition.  It 
structural  elements,  warhead  or  payload,  fuze,  safety /arming  devices,  guidance  equipment,  and 
propeliant/propulsion  equipment.  For  artillery  ammunition,  the  complete  round  consists  of  the  projectile 
including  structure,  warhead,  ruze,  guidance  and  control  (if  applicable),  safety/arming  devices,  propelling 
charge,  and  rodoet  motor  (if  applicable).  It  also  includes  the  design,  development,  and  production  of  complete 
units  (i.e.,  the  prototype  or  operationally  configured  unhs  which  satisfy  the  requirements  of  their  applicable 
specification^),  regardless  of  end  use). 

40.1.1.1  Structure.  The  structure  element  refers  to  the  portion  of  the  complete  round  which  carries  the  payload 
to  the  target.  It  is  the  basic  housing  of  a  bomb  or  rocket,  casing  of  a  projectile,  body  of  a  torpedo,  or  the 
tactical  munitions  dispenser  containing  submunitions.  It  also  inrimfe*  those  structural  devices  which  provide 
Stability  and  control  (i.e.,  fins,  parachutes,  anchors).  All  effort  directly  associated  with  the  remaining  level  3 
WBS  elements  and  the  integration,  assembly,  test  and  checkout  of  these  elements  into  the  mmpiww  round  is 
excluded. 

40.1.1.2  Payload,  The  payload  element  refers  to  the  subsystem  th»i  contains  the  warhead  and  u* support 
assemblies.  In  some  munitions,  such  «  small  arms  amruumtioti,  the  paylo»d  nay  only  be  the  warhead  (i.e.,  a 
projectile  assembly  containing  the  lull  mechanism  of  the  round  and  its  associated  high  explosives,  chemicals, 
biological  agents,  nuclear  devices,  and  pyrotechnics).  With  complex  munitions  containing  submunitions,  as 
Combined  Effects  Munitions,  the  payload  subsystem  may  include  guidance  and  control,  fuze,  safety /aim,  and 
propulsion  as  defined  in  40.1.1.3,  40.1.1  4,  40.1 .1.5,  and  40.1.1.6  of  this  appendix.  All  effort  directly 
associated  with  the  remaining  level  3  WBS  elements  and  the  integration,  assembly,  test  and  checkout  of  these 
elements  into  the  complete  round  is  excluded. 

40.1.1 .3  Guidance  and  Control.  The  guidance  and  control  dement  refers  to  the  complex  of  electronic 
equipment  (haidwarc/software)  which  evaluates  and  correlates  the  path  of  the  complete  round  with  target 
information,  and  which  performs  the  necessary  functions  to  enable  the  payload  to  intercept  the  target.  All  effort 
directly  associated  with  the  remaining  level  3  WBS  elements  and  the  integration,  assembly,  test  and  checkout  of 
these  elements  into  the  complete  round  is  excluded. 

40.1.1.4  Fuze.  The  fuze  dement  refers  to  the  mechanical  or  dectronic  device  in  the  complete  round 

to  detonate  or  to  set  forces  into  action  to  detonate  the  charge  or  primer  under  desired  conditions.  All  effort 
directly  associated  with  the  remaining  level  3  WBS  elements  and  the  integration,  assembly,  test  and  checkout  of 
these  elements  into  the  complete  round  is  excluded. 


40. 1.1.5  Safety/ Arm.  The  safety/arm  element  refers  to  the  device  in  the  complete  round  which  controls  the 
capability  of  initiating  the  explosive  sequence  (e.g.,  mechanical,  hydrostatic,  inertial,  counters,  and  timers).  All 
effort  directly  associated  with  the  remaining  level  3  WBS  elements  and  (he  integration,  assembly,  test  and 
checkout  of  these  elements  into  the  complete  round  is  excluded. 
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40.1  1.6  Propulsion.  Tnc  propulsion  element  refers  to  the  chemical,  mechanical,  or  electrical  devices,  such  as 
explosive  powder  charges,  chemical  precision  initiation  charges,  electric  power  modules,  and  rochet  motors 
which  provide  i he  forces  to  transport  the  complete  round  from  the  launch  position  to  the  target.  For  artillery 
ammunition,  this  element  includes  the  cartridge  case,  if  applicable,  and  primer  as  well  as  the  explosive  charge 
itself.  All  effort  directly  associated  with  the  remaining  level  3  WBS  dements  and  the  integration,  assembly,  test 
and  checkom  of  these  elements  into  the  complete  round  is  excluded 

40.1.1.7  Integration.  Assembly.  Test  and  Checkout  The  integration,  assembly,  test  and  checkout  oanent 
include  all  efforts  as  identified  in  Appendix  H,  Work  Breakdown  Structure  Definitions,  Common  Elements 
(ref.  page  H-2),  to  provide  a  complete  round. 

40.1.2  Launch  System.  The  launch  system  element  refers  to  the  equipment  (hardware1 software)  for  controlling 
or  sending  forth  the  munitions  on  a  desired  course  or  trajectory  -  the  ordnance  system  leas  the  complete  round. 
It  is  defined  as  rifles,  artillery  pieces,  naval  guns,  mortar  cannon,  machine  guns,  and  the  equipment  for 
launching  torpedoes  and  rockets  or  dropping  bombs  (e.f,.,  the  launcher,  fire  control  equipment,  and  the  ready 
magazine).  It  includes  all  effort  associated  with  the  design,  development,  and  production  of  complete  units 
(i.e.,  the  prototype  or  operationally  configured  units  which  satisfy  the  requirements  of  their  applicable 
specification^),  regardless  of  cod  use). 

40.1.2.1  Ijuncher.  The  launcher  element  refers  to  the  structural  device  designed  to  support  and  hold 
munitions  in  position  for  firing  or  release  (c.g.,  suspension  and  release  systems,  rail,  rocket  pods,  mine  racks  or 
dispensers,  and  torpedo  tubes).  For  guns  and  artillery,  it  includes  tubes,  recoil  assemblies,  breech  mechanisms, 
mounts,  and  rifle  stocks.  All  effort  directly  associated  with  the  remaining  level  3  WBS  elements  and  the 
integration,  assembly,  test  and  checkout  of  these  elements  into  the  launch  system  is  excluded. 

40.1.2.2  Carriage.  The  carriage  element  refer*  to  the  primary  equipment  (hardware/software)  which  serves  as 
a  platform  to  accommodate  the  other  level  3  elements  and  provides  mobility  to  the  complete  launch  system 
(c.g.,  T-frame,  hull/chassis,  wheels,  tires,  tubes,  brakes,  hydraulics,  and  wcondaiy  power  fcaucriesugeneratora), 
which  are  an  integral  part  of  the  carriage  itself  and  not  directly  a  part  of  other  level  3  elements.  All  effort 
directly  associated  with  the  remaining  level  3  WBS  elements  and  the  integration,  assembly,  test  and  checkout  of 
these  elements  into  the  launch  system  is  excluded. 

40. 1 .2.3  Fire  Control.  The  fire  control  element  refers  to  the  equipment  (hardware/software)  for  controlling  the 
direction,  volume,  and  time  of  fire  or  release  of  munitions  through  the  use  of  electrical,  electronic,  optical,  or 
mechanical  systems,  devices  or  aids.  For  rifles  and  small  arms,  it  includes  sighting  devices  and  trigger 
mechanisms.  For  artillery,  naval  guns,  and  heavy  mortars,  it  additionally  includes  aiming  mechanisms  in 
traverse  and  elevation,  radar  and  other  sensors,  computers  and  other  equipment  for  perforating  fire  control 
computations.  For  air-dropped  munitions,  it  includes  gunsights,  intervalometers,  and  other  sensor  and 
computational  devices  for  controlling  the  release  of  the  munitions.  For  torpedoes,  it  includes  sonar  and  other 
sensors,  computers,  control  consoles,  and  devices  for  presetting  torpedo  speed  and  direction.  Ah  effort  directly 
associated  with  the  remaining  level  3  WBS  elements  and  the  integration,  assembly,  test  and  checkout  of  these 
elements  into  the  launch  system  is  excluded. 

40. 1 .2.4  Weyfy  Magsrine  The  ready  magazine  element  refers  to  the  structure  or  compartment  for  storing 
ammunition  or  explosives  in  a  rcady-for-use  condition  or  position  (e.g.,  part  of  a  gun  or  firearm  which  holds 
the  ammunition  ready  for  chambering  and  feed  mechanisms  for  placing  the  ammunition  in  a  petition  ready  for 
chambering).  All  effort  directly  associated  with  the  remaining  level  3  WBS  elements  and  the  integration, 
assembly,  test  and  checkout  of  these  elements  into  the  launch  system  is  excluded. 
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40. 1.2.5  Adapter  Kits.  The  adapter  kits  element  refers  to  ike  equipment  (hardware/ software)  for  adapting  the 
launch  system  to  particular  applications  (e.g.,  vehicle  adapter  kits  fer  adaptation  to  different  aircraft  models,  lots 
for  backpacking,  etc.).  All  effort  directly  associated  with  the  remaining  level  3  WBS  elements  and  the 
integration,  asscmoly,  test  and  checkout  of  these  dements  into  the  launch  system  is  excluded. 

40.1.2.6  Integration.  Assembly.  Test  and  Checkout.  The  integration,  assembly,  test  and  checkout  element 
includes  all  efforts  as  identified  in  Appendix  H,  Work  Breakdown  Structure  Definitions,  Common  Elements 
(ref.  pege  H-2),  to  provide  a  complete  launch  system 

Definitions  for  common  WBS  elements  applicant  to  the  ordnance  system  and  all  othet  defense  materiel  items 
tee  in  Appendix  H,  Work  Breakdown  Structure  Definitions,  Common  Elements  (tef.  pages  H-l  through  H-10). 
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APPENDIX  E 

WORK  BREAKDOWN  STRUCTURE  AND  DEFINITIONS 
SHIP  SYSfEMS 


10.  SCOPE 

10. 1  Thir.  appendix  pi ov ides  the  ship  system  work  breakdown  structure.  Definitions  for  the  ship  are  provided 
in  this  appendix.  Definitions  for  common  WBS  elements  applicable  to  the  ship  and  all  other  defense  materiel 
items  are  in  Appendix  H,  Work  Breakdown  Structure  Definitions,  Common  Elements.  This  work  breakdown 
structure  must  be  used  for  ship  acqutstuon  pricing  data,  ship  design,  weight  data,  configuration  management  and 
ILS  engineering  data.  It  is  permissible  for  the  contractor's  internal  work  breakdown  structure  to  differ  from 
these  summary  elements  with  the  approval  of  the  appropriate  government  organization.  The  approved  internal 
management  work  breakdown  structure  must  be  traceable  to  and  capable  of  being  reported  to  the  work 
breakdown  structure  and  definitions  defined  by  this  appendix.  This  appendix  is  a  mandatory  pan  of  l be 
standard.  The  information  contained  herein  is  intended  for  compliance. 

20.  APPUC ABLE  DOCUMENTS. 

This  section  is  not  applicable  to  this  appendix. 

30.  WORK  BREAKDOWN  STRUCTURE 

30.1  Levels.  The  following  is  the  work  breakdown  structure  for  a  ship  system. 

Level  I  Level  2  Level  3 

Ship  System 

Ship 

Hull  Structure 
Propulsion  Plant 
Electric  Plant 

Command  rnd  Surveillance 
Auxiliary  Systems 
Outfit  and  Furnishings 
Armament 

Integration/Engineering 

Ship  Assembly  and  Support  Services 


Systems  Engmeering/Program  Management 
System  Test  ami  Evaluation 

Development  Test  and  Evaluation 
Operational  Test  and  Evaluation 
Mock-ups 

Test  and  Evaluation  Support 
Test  Facilities 


E-l 


MIL-STD-881B 


Level  1  Level  2 

Training 


Data 


Peculiar  Support  Equipment 


Common  Support  Equipment 


Operaional/Site  Activation 


Industrial  Facilities 


Initial  Spams  and  Repair  Parts 


Level  3 


Equipment 

Services 

Facilities 


Technical  Publications 
Engineering  Data 
Management  Data 
Support  Data 
Data  Depository 


Test  and  Measurement  Equipment 
Support  and  Handling  Equipment 


Test  and  Measurement  Equipment 
Support  and  Handling  Equipment 


System  Assembly,  Installation  and  Checkout 
on  Site 

Contractor  Technical  Support 


Site  ConstRseties 
Site  Conversion 


Construction/Conversion/Expansion 
Equipment  Acquisition  or  Modernization 
Maintenance  (Industrial  Facilities) 


E-2 
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40.  DEFINITIONS 

40.1  Ship  System.  The  ship  system  element  refers  to  the  complex  of  equipment  (hardwarc/software),  data, 
services,  and  facilities  required  to  attain  the  capability  of  operating  or  supporting  the  operation  of  naval 
weapons,  or  performing  other  naval  tasks  at  sea. 

40. 1 . 1  Ship.  The  ship  element  refers  to  the  waterborne  vehicle  of  a  ship  system.  It  includes  all  types  of 
surface  and  subsurface  water  vehicles  such  as  combatants,  auxiliaries,  amphibious,  and  special-purpose  ships.  It 
includes  the  design,  development,  and  production  of  complete  units  (i.e.,  the  prototype  or  operationally 
configured  units  which  satisfy  the  requirements  of  their  applicable  specification^),  regardless  of  end  use). 

.  40. 1.1.1  Hull  Structure.  The  hull  structure  element  refers  to  the  assembled  main  hull  body  with  all  structure 
subdivision.  This  element  includes,  for  example,  shell  plating,  longitudinal  and  transverse  framing,  platforms 
and  decks,  superstructure,  foundations,  structural  bulkheads,  enclosures  and  sponsors;  castings,  forgings,  and 
welds;  fixed  ballast;  doors  and  closures;  long-posts,  masts,  and  service  platforms;  and  sonar  domes.  It  also 
includes  compartment  testing. 

40.1.1.2  Propulsion  Plan'..  The  propulsion  plant  clement  refers  to  those  major  components  installed  primarily 

for  propulsion  and  the  systems  necessary  to  make  these  components  operable.  This  element  includes,  for 
example,  boilers  and  energy  converters,  propulsion  units,  main  condensers  and  air  ejectors,  shafting,  bearings, 
propellers,  combustion  air  supply  system,  uptakes,  propulsion  control  equipment,  main  stream,  feed  water  and 
condensate,  circulating  and  cooling  water,  fuel  oil  service  and  lubricating  oil  system.  It  also  nuclear 

steam  generators,  reactors,  reactor  coolant  and  auxiliary  systems,  nuclear  power  plant  control,  and  radiation 
shielding. 

40. 1.1.3  Fiectric  Plant.  The  electric  plant  element  refers  to  the  power  generating  and  distribution  systems 
installed  pnmarily  for  ship  service  and  emergency  power  and  lighting.  This  element  includes,  for  example,  the 
electric  power  generation,  power  distribution  switchboards,  power  distribution  system,  and  lighting  system. 

40.1.1.4  Command  and  Surveillance.  The  command  and  surveillance  element  is  defined  as  all  equipment 
(hardware/software)  and  associated  systems  installed  to  receive  information  from  off-ship  source,  to  transmit  to 
off-ship  receivers,  and  io  distribute  information  throughout  the  ship.  It  also  includes  sensing  and  dura  systems 
required  for  navigation  and  weapon  fire  control.  This  element  includes,  for  example,  navigation  equipment, 
interior  communication  systems  and  equipment,  gun  fire  control  system,  nonelectronic  countermeasure  systems, 
electronic  countermeasure  systems,  missile  fire  control  systems,  antisubmarine  warfare  lire  control  and  torpedo 
fire  control  systems,  radar  systems,  radio  communication  systems,  electronic  navigation  systems,  space  vehicle 
electronic  tracking  systems,  sonar  systems,  electronic  tactical  data  systems,  and  all  associated  software. 

40.1.1.5  Auxiliary  Systems.  The  auxiliary  systems  element  is  defined  as  those  systems  required  for  ship 
control,  safety,  provisioning,  and  habitability.  It  includes  the  auxiliary  machinery  and  piping  systems;  the  huii 
mechanical  handling  systems;  and  ship  control  surfaces  such  as  rudders,  hydrofoils,  and  driving  planes.  This 
element  includes,  for  example,  heating,  ventilation  air  conditioning  systems;  refrigerating  spaces;  plant  and 
equipment;  gasoline,  JP-3,  all  liquid  cargo  piping,  oxygen- nitrogen  and  aviation  lubricating  oil  systems; 
plumbing  installation,  saltwater  service  systems,  fire  extinguishing  systems,  drainage,  ballast,  trimming,  heating, 
and  stabilizer  tank  systems;  fresh  water  system,  scuppers  and  deck  drains;  fuel  and  diesel  oil  filling,  venting, 
stowage  and  transfer  systems;  tank  heating  systems,  compressed  air  system,  auxiliary  steam,  exhaust  steam  and 
ste.uu  drains,  buoyancy  control  system,  distilling  plant;  and  steering  system,  mooring,  towing,  anchor  and 
aircraft  handling  systems,  deck  machinery,  elevato.s.  moving  stairways,  stores  strikedown  and  stores  handling 
equipment,  operating  gear  for  retracting  and  elevating  units,  aircraft  elevators;  aircraft  arresting  gear,  barriers, 
and  barricades;  catapults  and  jet  blast  deflectors,  replenishment  at  sea  and  cargo  handling  systems. 


E-3 
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40. 1 .  i  .6  Outfit  and  Furnishings.  The  outfit  and  furnishing  dement  is  defined  is  those  outfit  equipments  and 
furnishings  required  for  habitability  and  operability  which  are  not  specifically  included  in  other  ship  elements. 
This  clement  includes,  fin  example,  hull  fittings;  boats,  boat  stowage  and  handlings;  rigging  and  canvas;  ladders 
and  gratings;  nonstru aural  bulkheads  and  doors;  painting,  deck  covering,  hull  insulation;  storerooms,  stowage 
and  lockers;  equipment  for  utility  space,  workshops,  laboratories,  test  areas,  alley,  pantry,  scullery  and 
commissary  outfit;  furnishings  for  living  spaces,  offices,  control  centers,  machinery  spaces,  medical,  dental  and 
pharmaceutical  spaces;  and  nonptopulston  space  shielding. 

40.1.1.7  Armament.  The  armament  element  is  defined  as  the  complex  of  armament  and  related  ammunition 
handling,  stowage,  and  support  facilities;  and  cargo  munitions  handling,  stowage,  and  support  facilities.  This 
element  includes,  for  example,  guns,  and  gnu  mounts;  ammunition  handling  systems  and  stowage;  special 
weapons  handling  and  storage;  rocket  and  missile  launching  devices,  handling  systems  and  stowage;  air 
launched  weapons  handling  systems  and  stowage;  and  cargo  munitions  handling  and  stowage. 

40.1.1.8  Intcgration/Engincering.  The  mtegrarion/engineenng  dement  is  defined  as  that  engineering  effort  and 
related  material  associated  with  the  design,  development ,  and  rework  to  provide  the  ship  as  a  whole  exclusive  of 
that  included  under  the  Systems  Engineering/Program  Management  element.  This  element  includes,  for 
example,  construction  drawings,  engineering  calculations,  weighing  and  weight  calculation,  photographs, 
models,  and  shipbuilders  information  drawings. 

40.1.1.9  Shin  Assembly  and  Support  Services.  The  ship  assembly  and  support  services  element  is  defined  as 
those  efforts  and  material  associated  with  the  construction  which  cannot  be  logically  and  practicably  identified 
with,  or  related  to  other  level  3  elements.  This  element  includes,  for  example,  staging,  scaffolding,  and 
cribbing;  temporary  utilities  and  services;  molds,  templates,  jigs,  fixtures,  and  special  production  tools;  dry¬ 
docking,  inspection,  insurance,  launching,  and  delivery. 


Definitions  for  common  WBS  elements  applicable  to  the  ship  and  all  other  defense  materiel  items  are  found  in 
Appendix  H,  Work  Breakdown  Structure  Definitions,  Common  Elements  (ref.  pages  K-l  through  H-lu). 
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APPENDIX  F 

WORK  BR FA.' DOWN  STRUCTURE  AND  DEFINITIONS 
SPACE  SYSTEMS 


10.  SCOPE 

10. 1  This  appendix  provides  the  space  system  work  breakdown  structure.  Definitions  for  the  launch  vehicle, 
orbital  transfer  vehicle,  space  vehicle,  ground  command,  control,  communications  and  mission  equipment,  flight 
support  operations  and  services,  and  storage  are  provided  in  this  appendix.  Definitions  for  common  WBS 

el  emeu  is  applicable  to  the  space  system  and  all  other  defense  materiel  items  are  in  Appendix  H,  Work 
Breakdown  Structure  Definitions,  Common  Elements.  This  appendix  is  a  mandatory  part  of  the  standard.  The 
information  contained  herein  is  intended  for  compliance. 

20.  APPLICABLE  DOCUMENTS. 

This  section  is  not  applicable  to  this  appendix. 

30.  WORK  BREAKDOWN  STRUCTURE 

30.1  Levels.  The  following  is  the  work  breakdown  structure  for  a  space  system. 

Level  1  Level  2  Level  3 

Space.  System 


Launch  Vehicle 


Orbital  Transfer  Vehicle 


Propulsion  (Single  Stage  Only) 

Stage  1 

Stage  11... n  (As  Required) 

Strap-On  Units  (As  Required) 

Shroud  (Payload  Fairing) 

Guidance  and  Control 

Integration,  Assembly,  Test  and  Checkout 


Propulsion  (Single  Stage  Only) 

Stage  I 

Stage  II... n  (As  Required) 

Strep-On  Units  (As  Required) 

Guidance  and  Control 

Integration,  Assembly,  Test  aad  Checkout 


Space  Vehicle 

Spacecraft 

Payload  I...n  (As  Required) 

Reentry  Vehicle 

Orbit  Injector/Dispenser 

Integration,  Assembly,  Test  and  Checkout 
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Level  1 

Level  2 

LsysU 

Ground  Command,  Control,  Communications 
and  Mission  Equipment 

Sensor  I...n  (As  Required) 

Telemetry,  Tracking  and  Control 

External  Communications 

Data  Processing  Equipment 
ijtnneh  Equipment 

Auxiliary  Equipment 

• 

Systems  Engineering /Progrsm  Management 

System  Test  and  Evaluation 

Development  Test  and  Evaluation 

Operational  Test  and  Evaluation 

Mock-ups 

Test  and  Evaluation  Support 

Test  Facilities 

Training 

Equipment 

Services 

Facilities 

Data 

Technical  Publications 

Engineering  Data 

Management  Data 

Support  Data 

Data  Depository 

• 

Peculiar  Support  Equipment 

Test  and  Measurement  Equipment 

Support  and  Handling  Equipment 

Common  Support  Equipment 

Test  and  Measurement  Equipment 

Suppoit  and  Handling  Equipment 

Operational/Site  Activation 

System  Assembly,  Installation  and  Checkout 
on  Site 

Contractor  Technical  Support 

Site  Construction 

Sitc/Ship/Vehicie  Conversion 
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Level! 

Flight  Support  Operations 
and  Services 


Storage 


Industrial  Facilities 


Initial  Spares  and  Repair  Pans 


Uvd  3 


M*te7  Checkout/ Launch 
Mission  Control 
Tracking  and  CJ 

Recovery  Operations  and  Services 
Launch  Sire  Maintenance/Retuitaiahment 


Planning  and  Preparation 
Storage 

Transfer  and  Transportation 

Construction/Conversion/Eipansion 
Equipment  Acquisition  or  Modernization 
Maintenance  (Industrial  Facilities) 
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40.  DEFINITIONS 

40. 1  Sd*x  System.  The  space  system  element  refers  to  the  complex  of  equipment  (hardware/software),  data, 
services,  and  facilities  required  to  attain  and/or  maintain  an  operational  capability  in  space.  To  achieve  an 
operational  capability  in  space  it  is  necessary  to  have  the  ability  to  develop,  deliver,  and  maintain  mission  pay- 
load(s)  in  specific  orbit.  This  requires  the  ability  to  develop  and  produce  a  capability  for  the  placement, 
operation,  and  recovery  of  both  maimed  and  unmanned  space  systems.  Space  systems  include  launch  vehicles, 
orbital  transfer  vehicles,  shrouds,  space  vehicles,  communications,  command  and  control  facilities  and 
equipment,  and  any  mission  equipment  or  other  items  necessary  to  provide  an  operational  capability'  in  space. 

40.1.1  Launch  Vgjuclg  The  launch  vehicle  element  refers  to  the  primary  means  for  providing  initial  thrust  to 
place  a  space  vehicle  into  its  operational  environment.  The  launch  vehicle  is  the  prime  propulsion  portion  of  the 
complete  flyaway  (not  to  include  the  orbital  transfer  vehicle  and  space  vehicle).  The  launch  vehicle  rosy  be  of  a 
single-stage  or  multiple-stage  configuration.  This  dement  includes,  for  example,  the  structure,  propulsion, 
guidance  and  control ,  and  ail  other  ineptly  equipment  integral  to  the  launch  vehicle  as  an  entity  within  itself. 

It  also  includes  the  design,  development,  and  production  of  complete  units  (i.e.,  the  prototype  or  operationally 
configured  units  which  satisfy  the  requirements  of  their  applicable  specification(s),  regardless  of  end  use). 

40.1.1. 1  Propulsion  (Single  Stage  Only).  The  propulsion  element  refers  to  the  means  for  generating  the  launch 
vehicle  into  its  operational  orbit  or  its  intended  path.  This  dement  includes,  for  example,  the  engine,  structure, 
propellant  and  fuel,  distribution  and  control  of  propellant  and  fuel,  starting  means,  safety  devices,  and  internal 
environmental  control  when  grouped  as  a  functional  entity,  it  also  includes  the  design,  development, 
production,  and  assembly  efforts  to  provide  the  propulsion  subassembly  as  an  entity.  All  effort  directly 
associated  wife  fee  remaining  level  3  WBS  elements  and  the  integration,  assembly,  test  and  checkout  of  these 
elements  into  the  launch  vehicle  is  excluded. 

40.1.1.2  Stage  I.  This  element  refers  to  fee  launch  vehicle  stage  which  provides  initial  lift-off  propulsion  for 
the  complete  launch  vehicle  (flyaway)  and  cargo.  This  element  includes,  for  example,  the  structure,  propulsion,' 
controls,  instrumentation,  and  all  other  installed  subsystem  equipment  integral  to  the  stage  as  an  entity  within 
itself.  It  also  includes  fee  design,  development,  production,  and  assembly  effort;  to  provide  Stage  I  as  an 
entity.  Strap-on  units  are  excluded.  All  effort  directly  associated  with  fee  remaining  level  3  WBS  elements  and 
the  integration,  assembly,  test  and  checkout  of  these  elements  into  the  launch  vehicle  is  excluded. 

40.1.1.3  Stage  II... n  (As  Required).  This  element  refers  to  fee  second  and  subsequent  launch  vehicle  stages  (if 
applicable)  which  are  used  to  place  a  space  vehicle  into  its  operational  environment.  This  element  provides 
propulsion  following  separation  of  the  first  stage  and  subsequent  stages  (if  applicable),  and  includes  the 
structure,  propulsion,  controls,  instrumentation,  separation  subsystems,  and  all  other  installed  subsystem 
equipment  integral  to  the  stage  as  an  entity  within  itself.  It  also  includes  fee  design,  development,  production, 
and  assembly  efforts  to  provide  each  stage  as  an  entity.  Strap-on  units  are  excluded.  All  effort  directly 
associated  with  fee  remaining  level  3  WBS  dements  and  the  integration,  assembly,  test  and  checkout  of  these 
elements  into  t  ic  launch  vehicle  is  excluded. 

40  1.1.4  Strao-On  Units  (As  Rcauiredi.  In  the  event  strap-on  units  are  employed,  this  element  refers  to  the 
solid  or  liquid  propulsion  assemblies  feat  provide  additional  thrust  or  propellant  to  assist  the  launch  vehicle  in 
placing  a  spacecraft  into  its  operational  orbit.  This  element  refers  to  a  complete  set  of  strap-on  units  and 
includes,  for  example,  fee  case,  nozzle,  igniter,  tanks,  mounting  structure,  cordage,  etc.  It  also  includes  the 
design,  development,  production,  and  assembly  efforts  to  provide  the  strap-on  units  as  an  entity.  All  effort 
directly  associated  wife  fee  remaining  level  3  WBS  elements  and  fee  integration,  assembly,  test  and  checkout  of 
these  elements  into  the  launch  vehicle  is  excluded. 
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40. 1 . 1 .5  Shroud  (Pavload  Fairing.').  This  element  refers  to  the  protective  covering  and  equipment  which  is 
mated  to  the  launch  vehicle  and  protects  the  cargo  (i.e.,  orbi'  J  transfer  vehicle  or  space  vehicle/orbiul  transfer 
vehicle  combination)  prior  to  and  during  the  launch  vehicle  ascent  phase.  This  item  includes  the  structure, 
instrumentation,  separation,  power,  and  thermal  control  suT  systems,  and  integration,  assembly,  test  and 
checkout.  The  structure  include.,  for  example,  the  shroud  structure,  mechanisms  and  hinges.  The 
instrumentation  includes  hardware  and  software  required  to  measure  the  environment  and  loads  being 
experienced  by  tbe  shroud  during  the  ascent  phase  until  shroud  separation  and  deployment.  The  separation 
subsystem  includes,  for  example,  the  sequencers,  ordnance,  and  other  necessary  mechanisms  to  assure  a 
successful  shroud  separation  from  the  launch  vehicle  and  cargo.  The  power  system  provides  the  necessary 
generation,  storage  and  distribution  of  electrical  power  and  signals,  hydraulic  power,  and  any  other  power 
required  by  the  shroud.  The  thermal  control  system  maintain*  (within  allowable  limits)  the  temperature  of  the 
shroud  and/or  any  mission  equipment  within  it.  The  thermal  control  function  may  be  accomplished  either 
passively  or  actively.  This  includes,  for  example,  thermal  paint,  insulation,  and  heatiindd  tiles. 

40.1.1.6  Guidance  and  Control.  The  guidance  and  control  equipment  (hardware/ software)  refers  to  the  means 
for  generating  or  receiving  guidance  intelligence,  conditioning  tbe  intelligence  to  produce  control  signals,  and 
generating  appropriate  control  forces.  Controllers  may  interface  with  tbe  structure  by  actuating  moveable  aero 
surfaces  or  with  the  propulsion  system  to  produce  control  reaction  forces  or  may  independently  produce  reaction 
forces  for  control.  If  the  design  is  such  that  electronics  are  packaged  into  a  siugle  rack  or  housing  as  an 
assembly,  this  rack  oi  bousing  will  be  considered  pan  of  the  guidance  and  control  system.  This  element 
includes,  for  example,  the  guidance  intelligence  system,  coiaputer,  sensing  elements,  etc.  All  effort  directly 
associated  with  the  remaining  level  3  WBS  elements  and  the  integration,  assembly,  test  and  checkout  of  these 
elements  into  the  launch  vehicle  is  excluded. 

40. 1 . 1.7  Inter  ration.  Assembly.  Test  and  Checkout,  The  integration,  assembly,  test  and  checkout  element 
includes  all  efforts  as  identified  in  Appendix  H,  Work  Breakdown  Structure  Definitions,  Common  Elements 
(ref.  page  H-2),  to  provide  a  complete  launch  vehicle. 

40.1.2  Orbital  Transfer  Vehicle.  The  otbital  transfer  vehicle  refers  to  any  transportation  system  which  is 
utilized  for  placing  spacecraft  ;n  an  operational  environment  following  launch  vehicle  separation/deployment. 
Orbital  transfer  /ehicle  includes,  for  example,  'upper-stages’  and  orbital  maneuvering  vehicles.  The  orbital 
transfer  vehicle  may  be  of  a  single-stage  or  multiple-stage  configuration.  This  element  includes  the  structure, 
propulsion,  guidance  and  control,  all  other  installed  equipment,  and  all  software  integral  to  the  vehicle.  It  also 
includes  the  design  development,  and  production  of  complete  units  (i.e.,  the  prototype  or  operationally 
configured  units  which  satisfy  the  requiremmts  of  their  applicable  specification(s),  regardless  of  end  use). 

40.1.2.1  Propulsion  (Single  Stage  Only).  Tbe  propulsion  element  refers  to  the  means  for  generating  the  orbital 
transfer  vehicle  into  its  operational  orbit.  This  element  includes,  foT  example,  the  engine,  structure,  propellant 
and  fuel,  distribution  and  control  of  propellant  and  fuel,  starting  means,  safety  devices,  and  internal 
environmental  control  when  grouped  as  a  functional  entity.  It  also  includes  the  design,  development, 
production,  and  assembly  efforts  to  provide  the  propulsion  structure  as  an  entity.  All  effort  directly  associated 
with  the  remaining  level  3  WBS  elements  and  the  integration,  assembly,  test  and  checkout  of  these  elements  into 
the  orbital  transfer  vehicle  is  excluded. 

40.1.2.2  Stage  I.  This  dement  refers  to  the  orbital  transfer  vchide  stage  which  provides  initial  propulsion  for 
the  orbital  transfer  vehicle  following  separation  or  deployment  from  the  launch  vehicle.  This  includes,  for 
example,  the  structure,  propulsion,  controls,  instrumentation,  separation,  and  all  other  installed  subsystem 
equipment  integral  to  the  stage  as  an  entity  within  itself.  It  also  includes  toe  design,  development,  production, 
and  assembly  efforts  to  provide  Stage  I  as  an  entity.  Strap-on  units  are  excluded.  All  effort  directly  associated 
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with  the  remaining  level  3  WBS  elements  and  the  integration,  assembly,  test  and  checkout  of  these  elements  >nto 
the  orbital  transfer  vehicle  is  excluded. 

40.1.2.3  Stage  II... n  (As  Required).  This  element  refers  to  the  second  orbital  transfer  vehicle  stage  and 
subsequent  stages  (as  required)  which  are  used  to  place  a  space  vehicle  into  its  operational  environment.  This 
provides  propulsion  following  separation  of  the  first  stage,  and  includes  the  structure,  propulsion,  controls, 
instrumentation  separation  subsystems,  and  all  other  installed  subsystem  equipment  integral  to  the  stage  as  an 
entity  within  itself.  It  alto  includes  the  design,  development,  production,  and  assembly  efforts  to  provide  each 
stage  as  an  entity.  Strap-era  units  are  excluded.  All  effort  directly  associated  with  /be  remaining  level  3  WBS 
elements  and  the  integration,  assembly,  test  and  checkout  of  these  elements  into  the  orbital  transfer  vehicle  is 
excluded. 

40. 1.2.4  Strap-On  Units  (As  Required).  In  the  event  strap-on  units  are  employed,  this  element  refers  to  the 
solid  or  liquid  propulsion  assemblies  that  provide  additional  thrust  or  propellant  to  assist  the  orbital  transfer 
vehicle  in  placing  a  space  vehicle  into  its  operational  orbit.  This  dement  refers  to  a  complete  set  of  strap-on 
units  and  includes,  for  example,  the  case,  aortic,  igniter,  tanks,  mounting  structure,  cordage,  etc.  It  also 
includes  the  design,  development,  production,  and  assembly  efforts  to  provide  the  strap-on  units  as  an  entity. 

All  effort  directly  associated  with  the  remaining  level  3  WBS  elements  and  the  integration,  assembly,  test  and 
checkout  of  these  elements  into  the  orbital  transfer  vehicle  is  excluded, 

40. 1 .2.5  Guidance  and  Control.  The  guidance  aad  control  equipment  (hardware/software)  refers  to  the  means 
for  generating  or  receiving  guidance  intelligence,  conditioning  the  intelligence  to  produce  control  signals,  and 
generating  appropriate  control  forces.  Controllers  may  interface  with  the  structure  by  actuating  moveable  aero 
surfaces  or  with  the  propulsion  system  to  produce  control  reaction  forces  or  may  independently  produce  reaction 
forces  for  control.  If  thr  design  is  soefa  that  electronics  are  packaged  into  a  single  rack  or  housing  as  an 
assembly,  this  rack  or  housing  will  be  considered  part  of  the  guidance  and  control  element.  This  element 
includes,  for  example  the  guidance  intelligence  system,  computer,  sensing  elements,  etc.  All  effort  directly 
associated  with  the  remaining  level  3  WBS  elements  aad  the  integration,  assembly,  test  and  checkout  of  these 
elements  into  the  orbital  transfer  vehicle  is  excluded. 

40.1.2.6  Integration.  Assembly.  Test  and  Checkout,  The  integration,  assembly,  test  and  checkout  dement 
includes  all  efforts  as  identified  in  Appendix  H,  Work  Breakdown  Structure  Definitions,  Common  Elements 
(ref.  page  H-2),  to  provide  a  complete  orbital  transfer  vehicle. 

40.1.3  Space  Vehicle.  The  space  vehicle  dement  refers  to  a  complete  vehicle,  or  group  of  vehicles  placed  into 
space  (operational  orbit  environment).  This  element  includes  spacecraft,  payload,  reentry  vehicle  and  orbit 
injection/dispenser  and  integration,  assembly,  test  and  checkout.  It  also  includes  the  design,  development,  and 
production  of  complete  units  (i.e. ,  the  prototype  or  operationally  configured  units  which  satisfy  the  requirements 
of  their  applicable  specificarion(s),  regardless  of  end  use). 

40.1.3.1  Spacecraft.  The  spacecraft  dement  refers  to  the  principal  operating  space  vehide  which  serves  as  a 
housing  or  platform  for  carrying  a  payload,  and  other  miss  ion -oriented  equipments  in  space.  This  dement 
includes,  for  example,  structure,  power,  attitude  determination  and  control,  and  other  equipments  characteristic 
of  spacecraft.  It  also  indudes  all  design,  development,  production,  arid  assembly  efforts  to  provide  the 
spacecraft  as  an  entity.  All  effort  directly  associated  with  the  remaining  levd  3  WBS  elements  and  the 
integration,  assembly,  test  and  checkout  of  these  elements  into  the  space  vehicle  is  excluded. 

40.1.3.2  Pavload.  The  payload  dement  refers  to  that  equipment  provided  for  special  purposes  in  addit.on  to 
the  normal  equipment  integral  to  the  spacecraft  or  reentry  vehicle.  It  includes,  for  example,  experimental 
equipment  placed  on  board  the  vehicle,  flight  crew  equipment  (space  suits,  life  support,  and  safety  equipment), 
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communications,  displays  and  instrumentation,  telemetry  equipment  and  other  equipments  that  am  specifically 
misskm-i.'rieau*l  to  collect  data  for  future  planning  and  projection  purposes.  All  effort  directly  associated  with 
the  remaining  level  3  WBS  elements  and  the  integration,  assembly,  test  and  checkout  of  these  elements  into  the 
space  vehicle  is  excluded. 

40.1.3.3  Reentry  Vehicle  The  reentry  vehicle  element  refers  to  the  principal  operating  vehicle  specifically 
designed  to  safely  reenter  the  atmosphere  in  order  to  land  a  payload  (experimental  equipment  or  crew).  This 
element  includes,  for  example,  navigation  and  guidance,  power  supply,  command  and  control,  attitude  control, 
environmental  control,  propulsion,  and  other  equipments  homogeneous  to  die  reentry  vehicle.  It  also  includes 
all  design,  development,  production,  and  assembly  efforts  to  provide  the  reentry  vehicle  as  an  entity.  All  effort 
directly -associated  with  she  remaining  level  3  WBS  elements  and  the  integration,  assembly,  test  and  checkout  of 
these  elements  into  the  space  vehicle  is  excluded. 

40.1.3.4  Orbit  Iniector/Disnenser.  The  orbit  injector/dispenser  el emenl  refers  to  the  function  of  placing 
orbiting  objects  in  the  planned  orbital  path.  This  element  includes,  for  example,  the  structure,  propulsion, 
instrumentation  and  stage  interface,  reparation  subsystem,  and  other  equipment  necessary  for  integration  with 
other  level  3  elements.  All  effort  directly  associated  with  the  remaining  level  3  WBS  dements  and  the 
integration,  assembly,  test  and  checkout  of  these  dements  into  the  space  vehicle  is  excluded. 

40.1.3.5  Integration.  Assembly.  Test  and  Checkout.  The  integration,  assembly,  test  and  checkout  element 
includes  all  efforts  as  identified  in  Appendix  H,  Work  Breakdown  Structure  Definitions,  Common  Elements 
(ref.  page  H-2),  to  provide  a  complete  space  vehicle. 

40.1.4  Ground  Command.  Control.  Communications  and  Mission  Equipment.  The  ground  command,  control, 
communications  and  mission  equipment  dement  refers  to  the  ground  hard  ware /software  equipment  used  for: 
communicating  between  control  and  tracking  facilities,  monitoring  the  health  and  status  of  space  vehicles, 
commanding  the  space  vehicle's  hardware,  adjusting  the  space  vehicle's  orbit  as  required  for  space  vehicle 
health  or  mission  purpose.  It  includes  the  design,  development,  and  production  of  complete  units  (i.e.,  the 
prototype  or  operationally  configured  units  which  satisfy  the  requirements  of  their  applicable  specification(s), 
regardless  of  end  use).  Examples  of  two  configurations  for  the  ground  command,  control,  communications  and 
mission  equipment  are:  the  parabolic  dish-based  antenna  system  and  the  phased  array-based  antenna  system.  If 
a  ground  site  has  multiple  antenna  configurations,  each  will  have  its  own  separate  command  and  control 
equipment,  communications  equipment,  data  processing  equipment  and  test  equipment. 

40.1.4.1  Sensor  l.-.n  (As  Required).  This  element  includes  those  hardware  and  software  elcments/componenu 
which  comprise  the  sensor  system.  Typical  hardware  normally  includes  the  antenna,  platfbrm/pedestal,  ratio  me, 
transmission  equipment,  reception  equipment  and  other  sensor  subsystems.  It  also  includes  the  design, 
development,  production,  and  assembly  efforts  to  provide  each  sensor  as  an  entity. 

40. 1 .4.2  Telemetry.  Tracking  and  Control.  The  telemetry,  tracking  and  control  dement  refers  to  the 
hardware/softwarc  elements  that  facilitate  launch  decisions  and  command  and  control  of  the  aerospace,  vehicle. 
This  dement  includes,  for  example,  supplementary  means  for  guidance  of  those  aerospace  vehicles  not  having 
completely  self-contained  guidance  and  control  and  means  to  command  destruct.  It  also  includes  control  and 
check-out  consoles,  data  displays,  and  mission  records. 

40. 1 .4.3  External  Communications.  The  external  communications  dement  includes,  for  example,  the 
hardware/soffware  components  that  allow  the  ground  station  to  communicate  with  any  external  data  link  or 
source  (i.e.. telephone  (analog)  lines,  digital  data  lines,  nonsatellite  radio  receivers).  While  the  terrestrial  data 
lines  may  connect  to  radio  of  other  satellite  communications  statiors,  the  external  communication*  subsystem 
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ends  where  these  links  physically  connect  to  the  secure  communications,  modulationy demodulation  (modem)  or 
coder/decoder  equipment. 

40. 1 .4  4  Data  Processing  Equipment  The  data  processing  equipment  includes  the  hardware/software 
components  that  provide  the  activities  and  means  to  condition  data  generated  at  the  launch  site  or  aboard  the 
space  vehicle,  or  data  received  from  associated  systems  to  accommodate  the  needs  of  command  and  control  or 
mission  data  processing.  This  element  includes,  for  example,  central  processing  unit  (computer),  peripheral 
equipment,  and  the  software  required  to  operate  the  data  processing  equipment. 

40. 1.4.5  Launch  Equipment.  The  launch  equipment  element  refen  to  the  means  to  launch  the  aerospace 
vehicle  from  stationary  sites.  This  element  may  include  storage  facilities  and  checkout  stations  tor  readiness 
verification  when  these  are  integral  to  the  launcher.  It  may  also  include  safety  and  protective  elements  when 
these  are  not  integral  to  the  launch  platform  or  facilities. 

40.1.4.6  Auxiliary  Equipment.  The  auxiliary  equipment  element  refers  to  the  general  puxpose/multi-usage 
ground  equipment  utilized  to  support  the  various  operational  capabilities  of  the  command  and  launch 
equipments.  This  dement  includes,  for  example,  power  generator*,  power  distribution  systems,  environmental 
control,  cabling,  malfunction  detection,  fire  prevention,  security  systems,  and  other  common-usage  items  not 
applicable  to  specific  elements  of  the  ground  based  equipment. 

40.1.5  Flight  Support  Operations  and  Services.  The  flight  support  operations  and  services  clement  refers  to  the 
mate/checkout/launch;  mission  control;  tracking;  and  command,  control  and  communications  (C5);  recovery 
operations  and  services;  and  launch  site  mair.enance/rtfurbishrDent.  This  element  supports  the  launch  vehicle, 
orbital  transfer  vehicle,  and/or  space  vehicle  during  an  operational  mission. 

40.1.5.1  MattVChectanit/Launch.  This  demem  refers  to  preflight  operations  and  services  subsequent  to 
production  and/or  storage,  and  the  actual  launch  of  me  complete  system  and  payload.  U  includes  effort  and 
materials  to  conduct  equipment  receiving  and  checkout  at  launch  site,  preflighi  assembly  and  checkout,  pre/post 
flight  data  reduction  and  analysis,  and  any  prelaunch  flight  control/missii.n  control  planning. 

40.1.5.2  Mission  Control.  The  mission  control  element  includes,  for  example,  the  personnel  and  material 
required  to  operate  individual  mission  control  centers  and  to  perform  ground  command  and  control  with  the 
space  vehicles.  It  includes  the  mission  control  centers  such  as,  Constellation  Command  Center,  the  Battle 
Management/Conunand  Control  Center  (BM/C5),  the  Space  Asset  Support  System  Control  Center,  and  the 
Space  Transportation  Control  Center.  (It  excludes  the  tracking  and  communications  centers;  these  are  included 
in  WBS  element  40.1.5.3.) 

40.1.5.3  Tracking  and  CJ.  The  tracking  and  C}  element  refers  to  the  personnel  and  material  required  to 
perform  the  functions  of  telemetry,  tracking,  controlling,  and  data  retrieval  for  the  mission  control  systems. 
These  systems  may  be  located  on  the  ground  or  ir  space,  such  as,  the  Satellite  Control  Facility  the  Remote 
Tracking  Station;  the  Tracking,  Data,  Relay  Satellite  System;  and  other  ground/space  tracking  systems.  (It 
excludes  the  initial  acquisition  of  the  tracking  and  C3;  acquisition  of  these  systems  are  included  in  WBS  element 
40.1.4.) 

40-1.5.4  Recovery  Operations  and  Services,  The  recovery  operations  and  services  element  refers  to  all 
contractor  effort  and  material  necessary  to  effect  recovery  of  the  space  vehicle  or  other  mission  equipment. 

This  element  includes,  for  example,  the  launch  site  recovery  forces,  reentry  site  recovery  forces,  logistics 
support  to  recovery  forces,  logistics  support  to  the  recovery  operations,  communications,  and  transportation  of 
recovered  equipment  to  assigned  facilities. 
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40.1.5.5  Launch  Site  Maintenance /Refurbishment .  The  launch  site  maintenanca/refurbisbmcnt  clement  refers 
ro  the  organization  ruaintenance/manageraent  of  launch  vehicle  facilities,  mission  equipment,  and  support  at  the 
iaunch  base.  This  element  includes  the  requirements  to  dean  up  and  refurbish  each  launch  site  after  each 
launch. 

40.1.6  Storage.  The  storage  dement  refers  to  those  costs  of  holding  portions  of  the  space  system  while 
awaiting  use  of  the  system.  These  periods  of  holding  are  those  resulting  from  set  while  changes  and/or 
technological  problems  exogenous  to  the  portion  of  the  space  system  being  stored,  prepared  for  storage,  or 
recovered  fiom  storage. 

40.1 .6. 1  Planning  and  Preparation.  The  planning  and  preparation  element  refers  to  ail  planning  and 
preparation  costs  for  the  storage  of  all  systems/subsystems  associated  with  the  launch  vehicle,  orbital  .  raster 
vehicle,  and  space  vehide  equipment.  It  includes  the  generation  cf  any  storage/ maintenance  instructions  sod 
documents  necessary  for  the  storage  and  maintenance  of  repairable  systems/ subsystems . 

40.1.6.2  Storage.  The  storage  element  refers  to  the  storage  and  maintenance  cost  incurred  while  the 
systems/subsystems  of  the  launch  vehicle,  orbital  transfer  vehide,  and  space  vehide  equipment  are  in  storage. 

40.1.6.3  Transfer  and  Transportation.  The  transfer  and  transportation  dement  refers  to  transfer  and  storage 
costs  incurred  when  the  systems/subsystems  of  the  launch  vehicle,  orbital  transfer  vehide,  and  spare  vehide 
equipment  are  required  to  be  transferred  bom  one  location  and  stored  in  another  location.  This  item  also 
includes  costs  of  relocating  systems/subsystems  from  one  storage  area  to  another  storage  area  when  necessitated 
by  mission  requirements. 

Definitions  for  common  WBS  elements  applicable  to  the  space  system  and  all  other  defense  materiel  items  are  in 
Appendix  H,  Work  Breakdown  Structure  Definitions,  Common  Elements  (ref.  pages  H-l  through  H-10). 
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APPENDIX  G 

WORK  BREAKDOWN  STRUCTURE  AND  DEFINITIONS 
SURFACE  VEHIC1E  SYSTEMS 


10.  SCOPE 

10. 1  This  appendix  provides  the  surface  vehicle  system  work  breakdown  structure.  Definitions  for  the  primary 
vehicle  and  secondary  vehicle  are  provided  in  this  appendix.  Definitions  for  common  WBS  elements  applicable 
to  the  surface  vehicle  and  all  other  defense  materiel  items  are  in  Appendix  H,  Work  Breakdown  Structure 
Definitions,  Common  Elements  (ref.  pages  H-l  through  H-10).  This  appendix  is  a  mandatory  part  of  the 
standard.  The  information  contained  herein  is  intended  for  compliance. 

20.  APPLICABLE  DOCUMENTS. 

This  section  is  not  applicable  to  this  appendix. 

30.  WORK  BREAKDOWN  STRUCTURE 

30.1  Levels.  The  following  is  the  work  breakdown  structure  for  a  surface  vehicle. 

Level  1  Level  2  LSY£L2 

Surface  Venicle  System 

Primary  Vehicle 

Huli/Frarne 

Suspcasion/Steenng 

Power  Package/Drive  Train 

Auxiliary  Automotive 

Turret  Assembly 

Fire  Control 

.Armament 

Body/Cab 

Automatic  Loading 

Automatic/Rernote  Piloting 

Nuclear.  Biological,  Chemical 

Special  Equipment 

Navigation 

Communications 

Integration,  Assembly,  Test  and  Checkout 
Secondary  Vehicle  Same  as  Primaiy  Vehicle 

Systems  Engineering/Program  Management 
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Level  1 


i 


Level  2 

System  Tes!  and  Evaluation 


Training 


Data 


Peculiar  Support  Equipment 


Common  Support  Equipment 


Operational /Site  Activation 


Industrial  Facilities 


Initial  Spares  and  (Repair  Pam 


Level  3 


Development  Test  and  Evaluation 
Operational  Test  and  Evaluation 
Mock-ups 

Test  tmd  Evaluation  Support 
Teat  Facilities 


Equipment 

Services 

Facilities 


Technical  Publications 
Engineering  Data 
Management  Daw 
Support  Data 
Data  Depository 


Test  and  Measurement  Equipment 
Support  and  Handling  Equipment 


Test  and  Measurement  Equipment 

Support  and  Handling  Equipment 


System  Assembly,  installation  and  Checkout 
on  Site 

Contractor  Technical  Support 
Site  Construction 
Site  Conversion 


Construction/Conversion/Expansion 
Equipment  Acquisition  or  Modernization 
Maintenance  (Industrial  Facilities) 
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40.0  DEFINITIONS 

40.1  Surface  Vehicle  System.  The  am  face  vehicle  system  element  refers  to  the  complex  of  equipment,  data, 
service  and  facilities  required  to  develop  and  produce  a  vehicle  system  with  the  capability  to  navigate  over  the 
surface.  Surface  vehicle  category  includes  vehicles  primarily  intended  for  general  purpose  applications  and 
those  intended  for  mating  with  specialized  payloads.  This  element  includes  cargo  and  logistics  vehicles,  mobile 
work  units  and  combat  vehicles.  It  also  includes  combat  vehicles  serving  as  armored  weapons  platforms, 
reconnaissance  vehicles,  and  amphibians, 

40.1 .1  Primary  Vehicle.  The  primary  vehicle  element  refers  to  the  mobile  element  of  the  system  embodying 
means  tor  performing  operational  missions.  This  element  includes  means  of  provision  and  structure  for 
adaptation  of  mission  equipment  or  accommodations  for  disposable  loads.  It  also  includes  the  design, 
development,  and  production  of  complete  units  (i.e. ,  the  prototype  or  operationally  configured  units  which 
satisfy  the  requirements  of  their  applicable  spetification(s),  regardless  of  end  use). 

40.1.1.1  Hcll/Fnunc.  The  buli/freme  element  refers  to  the  vehicle's  primary  load  bearing  component  which 
provides  the  structural  integrity  to  withstand  the  operational  loading  stresses  generated  while  traversing  various 
terrain  profiles.  This  element  could  be  a  simple  wheeled  vehicle  frame  or  a  more  complicated  combat  vehicle 
hull  which  satisfies  not  only  the  structural  requirements  but  also  provides  armor  protection.  It  includes  all 
structural  subassemblies  and  appendages  which  attach  directly  to  the  primary  structure.  This  element,  for 
example,  includes  towing  and  lifting  fittings,  bumpers,  hatches  and  grilles.  It  also  includes  provision  to 
accommodate  other  subsystems  such  as  mountings  for  suspension,  weapons,  turret,  truck  body,  cab,  special 
equipment  loads,  etc.  All  effort  directly  associated  with  the  remaining  level  3  WBS  element*  and  the 
integration,  assembly,  test  and  checkout  of  these  elements  into  the  primary  vehicle  is  excluded. 

40.1.1.2  Suspension/Steering.  The  suspension/steering  element  refers  to  the  *T>*2n£  for  generating  tractive 
efforts,  thrust,  lift,  and  steering  forces  generally  at  or  in  nraxinjiiy  to  the  earth’s  surfer*  and  w?  spring  the 
vehicle  to  the  irregularities  of  the  surface.  This  element  includes,  for  example,  wheels,  tracks,  brakes,  and 
steering  gears  for  traction  and  control  functions;  and  rodder  thrust  devices  and  trim  vanes  for  amphibians.  It 
also  includes  springs,  shock  absorbers,  skirts,  and  other  suspension  members.  All  effort  directly  associated  with 
the  remaining  level  3  WBS  elements  and  the  integration,  assembly,  test  and  checkout  of  these  elements  into  the 
primary  vehicle  is  excluded. 

40.1.1.3  Power  Package/Drive  Train.  The  power  package/drive  train  element  refers  to  the  means  for 
generating  power  and  delivering  power  in  the  required  quantities  and  driving  rates  to  the  driving  member.  This 
element  includes  for  example,  engine-mounted  auxiliaries  such  as  sir  ducting  and  manifolds,  controls  and 
instrumentation,  exhaust  systems,  and  cooling  means.  It  also  includes  such  power  transport  components  as 
dutches,  transmission,  shafting  assemblies,  torque  converters,  differentials,  final  drivers,  and  power  takeoffs.  It 
may  include  brakes  and  steering  when  these  are  integral  to  power  transmission  rather  than  in  the 
suspension/steering  dement.  All  effort  directly  associated  with  the  remaining  lcvd  3  WBS  dements  and  the 
integration,  assembly,  test  and  checkout  of  these  dements  into  the  primary  vehide  is  excluded. 

40. 1 . 1 .4  Auxiliary  Automotive.  The  auxiliary  automotive  dement  refers  to  the  group  of  suhs^steins 
(hardware/software)  which  provide  services  to  all  of  the  primary  vehide  subsystems,  as  distinguished  from  the 
special  equipment  subsystems,  and  which  outfit  the  chassis.  This  element  includes,  for  example,  the  vehide 
electrical  or  electronics  system,  on-board  diagnostic^ prognostics  system,  fire  extinguisher  system  and  controls, 
chassis  mounted  accessories  such  as  flic  winch  and  power  take-off,  tools  and  on-vehicle  equipment.  When 
otherwise  not  provided  for,  it  includes  crew  accommodations  All  effort  directly  associated  with  the  remaining 
luvel  3  WBS  elements  and  the  integration,  assembly,  test  and  checkout  of  these  elements  into  the  primary 
vehicle  is  excluded. 
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40.1.1.5  Turret  Assembly.  The  turret  assembly  element  refers  to  the  structure  end  equipment  injunctions 
required  to  provide  the  fighting  compartment  dement  of  combatant  vehicles.  This  element  includes  turret  armor 
and  radiological  shielding,  tun'd  rings,  slip  rings,  attachments  and  appendages  such  as  batches  and  cupolas,  and 
accommodations  for  personnel,  weapons,  and  command  and  control.  It  excludes  fire  control  and  stabilization 
system.  All  effort  directly  associated  with  tbe  remaining  level  3  WBS  elements  and  the  integration,  assembly, 
test  and  checkout  of  these  elements  into  tbe  primary  vehicle  is  excluded. 

40.1.1.6  Fire  Control .  The  fire  control  element  refers  to  that  equipment  (hardware/software)  installed  in  the 
vehicle  which  provides  intelligence  necessary  for  weapons  delivery  such  as  launching  and  firing.  This  element 
includes,  for  example,  radars  and  other  sensors  necessary  for  search,  recognition  and/or  tracking;  controls  and 
displays;  sight*  or  scopes;  range  finders,  computers,  computer  programs,  turret  and  gun  drives,  acd  stabilization 
systems  All  effort  directly  associated  wnh  the  remaining  level  3  WBS  elements  and  the  integration,  assembly, 
test  and  checkout  of  these  elements  into  the  primary  vehicle  is  excluded, 

40. 1 . 1 .7  Armament.  Tbe  armament  element  refers  to  the  means  for  combatant  vehicles  to  deliver  fire  on 
hostile  targets  and  for  logistics  and  other  vehicles  to  exercise  self-defense.  This  element  includes,  for  cxa  rple, 
the  main  gun,  launchers,  and  secondary  armament.  Fire  control  systems  are  excluded.  All  effort  directly 
associated  with  the  remaining  level  3  WBS  elements  and  the  Integration,  assembly,  test  and  checkout  of  these 
elements  into  the  primary  vehicle  is  excluded. 

40.1.1.8  Bodv/Cab.  The  body/cab  element  refers  to  the  major  component  to  be  mated  to  >  chassis  to  provide  a 
complete  vehicle  having  a  defined  mission  capability.  This  element  includes  accommodations  for  personnel , 
cargo,  and  such  subsystems  as  need  to  be  placed  in  proximity  to  operators.  All  effort  directly  associated  with 
tbe  remaining  level  3  WBS  elements  and  the  integration,  assembly,  test  and  checkout  of  these  eluncnu  into  the 
primary  vehicle  is  excluded. 

40.1 .1.9  Automatic  Loading.  The  automatic  loading  dement  consists  of  that  equipment  (hantware/aoftware) 
providing  the  means  to  select  ammunition  from  a  stored  position  ia  the  vehicle  and  tmufaiwg  io  *uri  loading 
the  armament  system.  This  element  also  includes  tbe  means  to  eject  span  cases  and  misfired  rounds. 
Components  include  all  ammunition  storage  racks,  transfer/lift  mechanisms,  ramming  and  ejecting  mechanisms 
as  well  as  specialized  hydraulic  and  electrical  controls.  All  effort  directly  associated  with  the  remaining  level  3 
WBS  elements  and  the  integration,  assembly,  vest  and  checkout  of  these  elements  into  the  primary  vehicle  is 
excluded. 

40. 1.1.10  Automatic/Rctpotc  Piloting.  The  automanc/rcmore  piloting  element  refers  io  that  equipment 
(haidware/software)  installed  in  the  vehicle  which  is  used  to  plan  and  control  vehicle  speed  and  direction  either 
autonomously  or  via  tele-operation.  This  includes  equipment  which  senses,  processes  and  displays  imagery  data 
such  as  stereo  vision  systems,  laser  scanners,  multiple  sensor  fusion  algorithms  and  processors,  image 
enhancement  algorithms  and  processors,  etc.  This  also  includes  equipment  which  performs  intelligence  analysis 
and  planning  functions  such  as  automated  route  planners,  image  undemanding  algorithms  and  processors, 
computer  aided  driving  algorithms  and  processors,  etc.  All  effort  directly  associated  with  the  remaining  level  3 
WBvS  elements  and  the  integration,  assembly,  test  and  checkout  of  these  elements  into  the  primary  vehicle  is 
excluded. 

40.1.1.11  Nuclear,  Biological.  Chemical.  The  nuclear,  biological,  chemical  element  refers  to  those 
subassemblies  or  components  which  provide  nuclear,  biological,  chemical  protection  and  survivahility  to  the 
vehicle  crew,  either  individually  or  collectively,  during  a  nuclear,  biological,  chemical  attack.  This  includes  a 
positive  pressure  system;  micro-climate  cooling;  air  conditioning  and  purification  system;  vearibted  face  piece 
(mask);  nuclear,  biological,  chemical  detection  and  warning  devices;  decontamination  kits;  and  chemical 
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resistant  coatings.  All  effort  directly  associated  with  the  remaining  level  3  WBS  elements  and  the  integration, 
assembly,  test  and  checkout  of  these  elements  into  the  primary  vehicle  is  excluded. 

40.1.1.12  Special  Equipment.  The  special  equipment  element  refers  to  that  special  equipment 
(haidwart/software)  to  be  mated  to  a  chassis  or  a  chassis/body/cab  assembly  to  enable  the  achievement  of  a 
special  mission  capability.  It  includes  all  items  required  to  convert  basic  vehicle  configurations  to  special- 
purpose  configurations.  This  element  includes,  for  example,  blades,  booms,  winches,  robotic  arms  or 
manipulators,  etc.,  to  equip  wreckers,  recovery  vehicles,  supply  vehicles  and  other  Field  work  units,  it  also 
includes  the  furnishings  and  equipment  for  command,  shop,  medical  and  other  special-purpose  vehicles.  All 
effort  directly  associated  with  the  remaining  level  3  WBS  elements  and  the  integration,  assembly,  test  and 
checkout  of  these  elements  into  the  primary  vehicle  is  excluded. 

40.1.1.13  Navigation.  The  navigation  element  refers  to  that  equipment  (hardware/toftware)  installed  in  the 
vehicle  which  permits  the  crew  to  determine  vehicle  location  and  to  plot  the  course  of  the  vehicle.  It  includes 
navigation  systems  such  as  dead  reckoning,  inertial,  and  global  pc  itioning  systems.  Landmark  recognition 
algorithms  and  processors  are  also  included.  All  effort  directly  associated  with  the  remaining  level  3  WBS 
elements  and  the  integration,  assembly,  test  and  checkout  of  these  elements  into  the  primary  vehicle  is  excluded. 

40.1.1.14  Communications.  The  communications  element  refers  to  that  equipment  (hardware/software j  which 
provides  the  means  within  the  system  for  commanding,  controlling,  and  transmitting  information  to  vehicle 
crews  and  other  personnel  exterior  to  operating  vehicles.  This  element  includes  radio  frequency  equipment, 
microwave  and  fiber  optic  communication  links,  networking  equipment  for  multiple  vehicle  control,  and 
intercom  and  external  phone  systems.  It  also  includes  the  means  for  supplementary  communication  such  as 
visual  signaling  devices.  It  may  include  navigation  system  and  data  displays  when  these  are  not  integral  with 
the  equipment  of  crew  stations  of  the  turret  assembly  or  the  driver’s  automotive  display  of  a  cab.  All  effort 
directly  associated  with  the  remaining  level  3  WBS  elements  and  the  integration,  assembly,  test  and  checkout  of 
these  elements  into  the  primary  vehicle  is  excluded. 

40.1.1.15  Integration.  Assembly.  Test  and  Checkout.  The  integration,  assembly,  test  and  checkout  element 
includes  all  efforts  as  identified  in  Appendix  H,  Work  Breakdown  Structure  Definitions,  Common  Elements 
(ref.  page  H-2),  to  provide  a  complete  surface  vehicle. 

40.1.2  Secondary  Vehicle.  The  secondary  vehicle  element  refers  to  these  vehicles  required  to  supplement, 
expand,  or  otherwise  contribute  to  the  capabilities  of  primary  vehicles  to  provide  the  hide  system  with  the 
required  operational  characteristics.  Secondary  vehicles  are  not  necessarily  self-conta.ued  operational  units 
capable  of  operating  outside  the  system.  This  element  includes,  for  example,  cargo  and  tank  trainers  of  truck- 
trailers  systems,  carriers  and  tanker  units  of  articulated  train-type  systems,  and  transporters  as  employed  in 
systems  when  the  primary  vehicle  had  limited  roadability.  It  also  includes  the  design,  development,  and 
production  of  complete  units  (i.e.,  the  prototype  or  operationally  configured  units  which  satisfy  the  requirements 
of  their  applicable  specification(s),  regardless  of  end  use),  The  work  breakdown  structure  and  definitions  for 
secondary  vehicle  will  be  the  same  as  specified  for  the  primary  vehicle. 

Definitions  for  common  WBS  elements  applicable  to  the  surface  vehicle  and  all  other  defense  materiel  items  are 
in  Appendix  H.  Work  Breakdown  Structure  Definitions,  Common  Elements  (ref.  pages  H-l  through  H-10). 
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APPENDIX  K 

WORK  BREAKDOWN  STRUCTURE  DEFINITIONS 
COMMON  ELEMENTS 


10.  SCOPE 

10. 1  This  appendix  provides  the  work  breakdown  structure  and  definitions  for  common  WBS  elements 
applicable  to  all  types  of  systems.  This  appendix  is  a  mandatory  part  of  tbs  standard.  The  information 
contained  herein  is  intended  for  compliance. 

20.  APPLICABLE  DOCUMENTS 


20.1 


20.1.1  Specifications.  Standards,  and  Handbooks.  The  following  specifications,  standards,  and  handbooks 
form  a  pan  of  this  document  to  the  extent  specified  herein.  Unless  otherwise  specified,  the  issues  of  these 
documents  are  those  listed  in  the  issue  of  the  Department  of  Defense  Index  of  Specifications  (DODISS)  and 
supplement  thereto,  cited  in  the  solicitation. 


STANDARDS 

MIL-STD-499 
MEL-STD-1388-1 
MIL- STD-1464 
MIL-STD-166! 
MIL- STD-1812 


Engineering  Management 

Logistic  Support  Analysis 

Army  Nomenclature  System 

Mark  and  Mod  Nomenclature  System 

Type  Designation,  Assignment  and  Method  for  Obtaining 


(Unless  otherwise  indicated,  copies  of  federal  and  military  specifications,  standards,  and  handbooks  are  available 
from  the  Standardization  Documents  Order  Desk,  700  Robbins  Avenue,  Building  #4,  Section  D,  Philadelphia, 
PA  19111-5094.) 


20.1.2  Other  Government  Documents.  Drawings,  and  Publications.  The  following  other  Government 
documents,  drawings,  and  publications  form  a  part  of  this  document  to  the  extent  specified  herein.  Unless 
otherwise  specified,  the  issues  are  those  cited  in  the  solicitation. 


DOD  5010. 12-L  Acquisition  Management  Systems  and  Data  Requirements  Control  List  (AMSDL)  - 

(Copies  of  DOD  5010. 12-L  are  available  from  the  Standardization  Documents  Order  Desk,  700  Robbins 
Avenue,  Building  #4,  Section  D,  Philadelphia,  PA  19111-5094. 

20.2  Non-Government  Publications.  This  section  is  not  applicable  to  this  standard. 
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30.  DEFINITIONS 

30. 1  Integration.  Assembly.  Test  and  Checkout .  In  these  instances  in  which  an  integration,  assembly,  test  and 
checkout  element  is  used  (Appendices  A  through  G),  it  will  include  all  effort  of  technical  and  functional 
activities  associated  with  the  design,  development,  and  production  of  mating  surfaces,  structures,  equipment, 
parts,  materials,  and  software  required  to  assemble  the  level  3  equipment  (hardware/ software)  elements  into  a 
level  2  mission  equipment  (hanJware/softwarr)  as  a  whole  and  not  directly  part  of  any  other  individual  level  3 
element.  Integration,  assembly,  test  and  checkout  includes  all  effort  associated  with  the  following: 

a.  The  development  of  engineering  layouts,  determination  of  overall  design  characteristics,  and 
determination  of  requirements  of  design  review 

b  The  set  up,  conduct  and  review  of  testing  assembled  components  or  subsystems  prior  to  installation 

c.  The  detailed  production  design,  pnxiucibility  engineering  planning  (PEP),  awl  manufacturing 
process  capability,  including  the  process  design  development  and  demonstration  effort  to  achieve 
compatibility  with  engineering  requirements  and  the  ability  to  produce  economically  and  consistent 
quality 

d.  Inspection  activities  related  to  receiving,  factory  and  vendor  Irison 

e.  Design  maintenance  effort 

f.  Quality  planning  and  control 

g.  Tooling  (initial  production  facilities,  factory  support  equipment)  including  its  planning ,  design  and 
fabrication 

h.  Administrative  engineering 

i.  The  joining  or  mating  and  final  assembly  of  level  3  equipment  elements  to  form  a  complete  prime 
mission  equipment  when  the  effort  is  performed  at  the  manufacturing  facility 

j .  Integration  of  software  (including  the  loading  and  verification  of  firmware) 

k.  The  conduct  of  production  acceptance  testing 

Integration,  assembly,  test  and  checkout  excludes  all  systems  engineering/prograrp  management  and 
system  test  and  evaluation  which  are  associated  with  the  overall  system. 

When  an  integration,  assembly,  test  and  checkout  element  is  utilized  at  lower  levels  of  the  contract 
work  breakdown  structure,  it  will  be  summarized  into  the  next  higher  level  equipment  (hardware/software)  work 
breakdown  structure  element  and  should  never  be  summarized  directly  into  a  level  3  integration,  assembly,  test 
and  checkout  element. 

30.2  Systems  Engineering/Program  Management,  The  systems  engineenng/program  management  element  is 
defined  as  the  systems  engineering  and  technical  control  as  well  as  the  business  management  of  particular 
systems  and  programs.  This  element  encompasses  the  overall  planning,  directing,  and  controlling  of  the 
definition,  development,  and  production  of  a  system  or  program,  including  functions  of  logistics  engineering  and 
integrated  logistics  support  (ILS)  management,  e.g.,  maintenance  support,  facilities,  personnel,  training,  testing, 
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and  activation  of  a  system.  Systems  eogmeering/progtam  management  effort  that  can  be  associated  specifically 
with  the  equipment  (hard ware/ software)  element  is  excluded.  Systems  engroeering/prognm  management 
elements  to  be  reported  and  their  levels  will  be  specified  by  the  requiring  activity.  Examples  of  systems 
engineering/program  management  elements  and  their  definitions  are  provided  as  foliov/s: 

a.  Systems  Engineering.  The  systems  engineering  element  is  defined  as  the  technical  and 
management  efforts  of  directing  and  controlling  c  totally  integrated  engineering  effort  of  a  system  or  program  as 
described  in  MIL-STD-499.  This  element  encompasses  the  systems  enginceripg  effort  to  define  the  system  and 
the  integrated  planning  and  control  of  the  technical  program  efforts  of  desigj  engineering,  specialty  engineering, 
production  engineering,  and  integrated  test  planning.  This  element  include  but  is  not  limited  to:  the  systems 
engineering  effort  to  transform  an  operational  seed  or  statement  of  defir^eocy  into  a  description  of  system 
requirements  and  a  preferred  system  configuration;  and  the  technical  manning  and  control  effort  for  planning, 
monitoring,  measuring,  evaluating,  directing  and  replanning  the  management  of  the  technical  program.  It 
specifically  excludes  the  actual  design  engineering  and  the  production  engineering  directly  related  to  the  WBS 
dement  with  which  it  is  associated.  Examples  of  systems  engineering  efforts  include: 

1)  System  definition,  overall  system  design,  design  integrity  analysis,  system  optimization, 
system/cost  effectiveness  analysis,  and  intra-system  and  inter-system  compatibility  assurance,  etc.:  <e 
integration  and  balancing  of  reliability,  maintainability,  producihility,  safety,  human  health,  cnvii  'mental 
protection,  and  survivability;  security  requirements,  configuration  management  and  configuration  control,  quality 
assurance  program,  value  engineering,  preparation  of  equipment  and  component  performance  specifications, 
design  of  test  and  demonstration  plans;  determination  of  software  development  or  software  test 
facility/environment  requirements; 

2)  Preparation  of  the  Systran  Engineering  Management  Plan  /SEMP),  specification  tree, 
program  risk  analysis,  system  planning,  derision  control  process,  technical  performance  measurement,  technical 
reviews,  subcontractor  and  vendor  reviev.s,  work  authorization,  and  technical  documentation  control; 

3)  Reliability  engineering  defined  as  the  engineering  process  and  series  of  tasks  required  to 
examine  the  probability  of  a  device  or  system  performing  its  mission  adequately  for  the  period  of  time  intended 
under  the  operating  conditions  expected  to  be  encountered; 

4)  Maintainability  engineering  defined  &'  the  engineering  process  and  series  of  tasks  required 
to  measure  the  ability  of  an  item  or  system  to  be  retained  in  or  restored  to  a  specified  condition  of  readiness, 
"kill  levels,  etc.,  using  prescribed  procedures  and  resources  at  specific  levels  of  maintenance  and  repair; 

3)  Human  factors  engineering  defined  as  the  engineering  process  and  the  nerics  of  tasks 
required  to  define,  as  a  comprehensive  technical  and  engineering  effort,  the  integration  of  doctrine,  manpower 
and  personnel  integration,  materiel  development,  operational  effectiveness,  human  characteristics,  skill 
capabilities,  training,  manmtig  implication,  and  other  related  elements  into  a  comprehensive  effort;  and, 

6)  Logistics  Support  Analysis  (LSA)  element  defined  by  MIL-STD-1388-1  as  the  selective 
application  of  scientific  and  logistic  engineering  tasks,  efforts  and  analysis  undertaken  during  the  acquisition 
process,  as  part  of  the  systems  engineering  and  design  effort,  to  assist  in  complying  with  suppartability  tu  cl 
other  ELS  objectives;  it  indudes,  but  is  not  limited  to,  the  generic  tasks  required  for  support  element 
detcnnrjatkm  and  the  analysis  required  to  identify  and  verify  its  adequacy. 

All  programs,  where  applicable,  include:  value  engineering,  configuration  management,  human 
factors,  maintainability,  reliability,  survivability /vulnerability,  system  safety,  environmental  protection, 
standardization,  systems  analysis,  logistics  support  analysis,  etc. 
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For  ships  this  includes  the  Extended  Ship  Work  Breakdown  Structure  (ESWBS)  Configuration 
Management  (811),  Human  Factors  (892),  Standardization  (893),  Value  Engineering  (894),  and  Reliability  and 
Maintainability  (895)  elements. 

b.  Program  Management  The  program  management  element  is  defined  as  the  business  and 
administrative  planning,  organizing,  directing,  coordinating,  controlling,  and  approval  actions  designated  to 
accomplish  overall  program  objectives  which  are  not  associated  with  specific  hardware  elements  and  are  not 
included  in  systems  engineering.  Examples  of  these  activities  are: 

1)  Cost,  schedule,  performance  measurement  management,  warranty  administration,  contract 
management,  data  management,  vendor  liaison,  subcontract  management,  cic. 

2)  1LS  element  management  defined  as  the  logistics  tasks  management  effort  and  technical 
control,  and  the  business  management  of  the  elements  of  1LS.  The  logistics  management  function  encompasses 
the  Integrated  Support  Plan  (ISP),  ILS  Management  Team  (ILSMT)  participation,  ILS  evaluation  and 

suppo liability  assurance  requited  to  produce  an  affordable  and  supportable  defense  materiel  system.  This 
element  includes  the  planning  and  management  of  all  the  functions  of  logistics  and  logistic  support  analysis, 
e  g.,  maintenance  support  planning;  support  facilities  planning;  other  ILS  requirements  determination;  support 
equipment;  supply  support;  Packaging,  Handling,  Storage,  and  Transportation  (PHST);  provisioning 
requirements  determination  and  planning;  training  system  requirements  determination;  computer  resource 
determination;  organizational,  intermediate,  and  depot  maintenance  determination  management;  and  data 
management. 

For  ships  this  includes  the  Extended  Ship  Work  Breakdown  Structure  (ESWBS)  Project  Management 
(897);  Data  Management  (896);  ILS  Engineering,  Maintenance  (851);  ILS  Engineering,  Support  and  Test 
Equipment  (852);  and  ILS  Engineering,  Supply  Support  (853)  dements. 

30.3  System  Test  and  Evaluation.  The  system  test  and  evaluation  element  refers  io  the  use  of  prototype, 
production,  or  specifically  fabricated  bardware/software  to  obtain  or  validate  engineering  data  on  the 
performance  of  the  system  during  the  development  phase  (normally  funded  from  RDT&E)  of  the  program.  This 
element  includes  the  detailed  planning,  conduct,  support,  data  reduction  and  reports  (excluding  the  Contract 
Data  Requirements  List  (CDRL)  data)  from  such  testing,  and  all  hardware/software  items  which  axe  consumed 
or  planned  to  be  consumed  in  the  conduct  of  such  testing.  It  also  includes  all  effort  associated  with  the  design 
and  production  of  models,  specimens,  fixtures,  and  instrumentation  in  support  of  the  system  level  test  program. 
NOTE:  Test  articles  which  are  complete  units  (i.e. ,  functionally  configured  as  required  by  specifications)  are 
excluded  from  this  work  breakdown  structure  element.  All  formal  and  informal  testing  up  through  the 
subsystem  level  which  can  be  associated  with  the  bardware/software  ciement  are  excluded.  Acceptance  testing 
is  also  excluded.  These  excluded  efforts  are  to  be  included  with  the  appropriate  hardware  or  software  elements. 

30.3.1  Development  Test  and  Evaluation.  The  development  test  and  evaluation  dement  refers  to  that  test  and 
evaluation  conducted  to:  (a)  demonstrate  that  the  engineering  design  and  development  process  is  complete;  (b) 
demonstrate  that  the  design  risks  have  been  minimized;  (c)  demonstrate  that  the  system  will  meet  specifications; 
(d)  estimate  the  system’s  military  utility  when  introduced;  (e)  determine  whether  the  engineering  design  is 
supportable  (practical,  maintainable,  safe,  etc,)  for  operational  use;  (f)  provide  test  data  with  which  to  examine 
and  evaluate  trade-offs  against  specification  requirements,  life  cycle  cost,  and  schedule;  and  (g)  perform  the 
logistics  testing  efforts  to  evaluate  the  achievement  of  supportability  goals,  the  adequacy  of  the  support  package 
for  the  system,  (e.g.,  deliverable  maintenance  tools,  test  equipment,  technical  publications,  maintenance 
instructions,  and  personnel  skills  and  training  requirements,  etc.).  Development  test  and  evaluation  includes  all 
contractor  in-house  effort  and  is  planned,  conducted  and  monitored  by  the  developing  agency  of  the  DoD 
Component . 
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All  programs,  where  applicable,  include  models,  tests  and  associated  simulations  such  as  wind  tunnel, 
static,  drop,  and  fatigue;  integration  ground  tests;  test  bed  aircraft  and  associated  support;  qualification  test  and 
evaluation  (QT&E),  development  flight  test,  test  instrumentation,  environmental  tests,  ballistics,  radiological, 
range  and  accuracy  demonstrations,  test  facility  operations,  test  efruipment  (including  its  support  equipment), 
chase  and  calibrated  pacer  aircraft  and  support  thereto,  and  logistics  testing. 

For  aircraft,  include avionics  integration  test  mnyrurd  of  the  following:  (a)  test  bench/labontory, 
including  design,  acquisition,  and  installation  of  basic  computers  and  test  equipments  which  will  provide  an 
ability  to  njireHte  in  die  laboratory  the  operational  environment  of  the  avionics  system/ subsystem;  (b)  air 
vehicle  equipment,  consisting  of  the  avionics  and/or  other  air  vehicle  subsystem  modules  which  are  required  by 
the  bench/lab  or  flying  test  bed  in  order  to  provide  a  compatible  airframe  avionics  system/ subsystem  for 
evaluation  purposes;  (c)  flying  test  bed,  including  requirements  analysis,  design  of  modifications,  lease  or 
purchase  of  test  bed  aircraft,  modification  of  aircraft,  installation  of  avionics  equipment  and  instrumentation,  and 
checkout  of  an  existing  aircraft  used  essentially  as  a  flying  avionics  laboratory;  (d)  avionics  test  program, 
consisting  of  the  effort  required  to  develop  test  plans/procedures,  conduct  tests,  and  analyze  hardware  and 
software  test  results  to  verify  the  avionics  equipments’  operational  capability  and  compatibility  as  an  integrated 
air  vehicle  subsystem;  and  (e)  software,  referring  to  the  effort  required  to  design,  code,  de-bug,  and  document 
software  programs  necessary  to  direct  the  avionics  integration  test. 

For  engines,  include  engine  military  qualification  tests  and  engine  preliminary  flight  rating  tests. 

For  ships,  include  model  basin,  hydrostatic,  fatigue,  shock,  special  sea  tests  and  trials,  etc.,  including 
the  Extended  Ship  Woik  Breakdown  Structure  (ESWBS)  Trials  Agenda  Preparation,  Data  Collection  A.  Analysis 
(842);  Dock  and  Sea  Trials  (9823);  and  Hull  Vibration  Survey  (9825)  dements. 

30.3.2  Operational  Tesr  and  Bvalnation.  The  operational  test  and  evaluation  dement  refers  to  that  ten  and 
evaluation  conducted  by  agencies  other  than  the  developing  command  to  assess  the  prospective  system’s  military 
utility,  operational  effectiveness,  operational  suitability,  logistics  aupportability  (including  compatibility ,  inter¬ 
operability,  reliability,  maintainability,  logistic  requirements,  etc.),  cost  of  ownership,  and  need  for  any 
modifications.  Initial  operational  test  and  evaluation  conducted  during  the  development  of  a  weapon  system  will 
be  included  in  this  element.  This  element  encompasses  such  tests  as  system  demonstration,  flight  tests,  sea 
trials,  mobility  demonstrations,  on-orbit  tests,  spin  demonstration,  stability  tests,  qualification  operational  test 
and  evaluation  (QOT&E),  etc.,  and  support  thereto,  required  to  prove  the  operational  capability  of  the 
deliverable  system.  It  includes  contractor  support  (e.g.,  technical  assistance,  maintenance,  labor,  material,  etc.) 
consumed  during  this  phase  of  testing.  It  also  includes  performing  the  logistics  testing  efforts  to  evaluate  the 
achievement  of  suppoitability  goals  and  the  adequacy  of  the  support  for  the  system  (e.g.,  deliverable 
maintenance  tools,  test  equipment,  technical  publications,  maintenance  instructions,  personnel  skills  and  training 
requirements,  and  software  support  facil ity / environment  elements). 

30-3-3  Mock-ups.  The  mock-ups  element  refers  to  the  design  engineering  and  production  of  ryUem  or 
subsystem  mock-ups  which  have  special  contractual  or  engineering  significance,  or  which  are  not  required  solely 
for  the  conduct  of  one  of  the  above  dements  of  testing. 

30-3.4  Tea  and  Evaluation  .Support.  The  test  and.  evaluation  support  element  refers  to  all  support  elements 
necessary  to  operate  and  maintain  systems  and  subsystems  during  test  and  evaluation  which  are  not  consumed 
during  the  testing  phase  and  are  not  allocated  to  a  specific  phase  of  testing.  This  element  includes,  for  example, 
repairable  spares,  repair  of  reparables,  repair  parts,  warehousing  and  distribution  of  spares  and  repair  parts,  test 
and  support  equipment,  test  bed  vehicles,  drones,  surveillance  aircraft,  tracking  vessels,  contractor  technical 
support,  etc.  Operational  and  maintenance  personnel,  consumables,  special  fixtures,  special  instrumentation, 
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etc.,  which  are  utilized  and/or  consumed  is  a  single  element  of  testing  and  which  should  therefore  be  included 
under  that  element  of  testing  are  excluded. 

30.3.5  Test  Facilities.  The  test  facilities  element  refen  to  those  special  test  facilities  required  for  performance 
of  the  various  developmental  tests  necessary  to  prove  the  design  and  reliability  of  the  system  or  subsystem. 

This  element  includes,  for  example,  test  tank  test  fixtures,  propulsion  test  futures,  white  rooms,  test  chambers, 
etc.  The  brick  and  mortar-type  facilities  identified  as  industrial  facilities  are  excluded. 

30.4  Tndninc.  The  training  element  is  defined  as  the  deliverable  training  services,  device*  accessories,  aids, 
equipment,  and  parts  used  to  facilitate  instruction  through  which  personnel  will  acquire  sufficient  concepts, 
skills,  and  aptitudes  to  operate  and  maintain  the  system  with  maximum  efficiency.  This  element  includes  all 
effort  associated  with  the  design,  development,  and  production  of  deliverable  training  equipment  as  well  as  the 
execution  of  training  services.  This  element  and  its  subelements  exclude  the  overall  planning,  management,  and 
task  analysis  function  inherent  in  the  WBS  element  Systems  Engmtering/Progrim  Management. 

30.4. 1  Equipment.  The  equipment  dement  is  defined  as  those  distinctive  deliverable  end  items  of  training 
equipment,  assigned  by  either  a  contractor  or  military  service,  required  to  meet  specific  training  objectives. 

This  dement  includes:  operational  trainers,  maintenance  trainers  and  other  items  such  as  cutaways,  mock-  ups, 
and  models. 

30.4.2  Services.  The  services  element  is  defined  as  the  deliverable  services,  accessories,  and  aids  necessary  to 
accomplish  the  objectives  of  training.  This  element  includes,  for  example,  training  course  materials; 
contractor-conducted  training  including  in-plant  and  service  training;  and  the  materials  and  curriculum  required 
to  design,  execute  and  produce  a  contractor  developed  training  program.  It  also  includes  the  material,  courses,  • 
and  associated  documentation  (primarily  the  computer  software,  courses  and  training  aids).  This  element 
excludes  the  deliverable  training  data  associated  with  the  WES  dement  Support  Data. 

• 

30.4.3  Facilities.  The  facilities  element  refers  to  the  special  construction  necessary  to  accomplish  training 
objectives.  It  also  includes  the  modification  or  rehabilitation  of  existing  facilities  used  to  accomplish  training 
objectives.  The  installed  equipment  used  for  the  purpose  of  acquainting  the  trainee  with  the  system  or 
establishing  trainee  proficiency  is  excluded.  The  brick  and  mortar-type  facilities  identified  as  industrial  facilities 
are  also  excluded. 

1.5  Data.  The  data  element  refers  to  all  deliverable  data  t^quiied  to  be  listed  on  a  Contract  Data 
'quiremeats  List,  DD  Form  1423.  The  data  requirements  will  be  selected  from  the  Acquisition  Management 
■terns  and  Data  Requirements  Control  List  (DoD  5010. 12-L).  This  dement  includes  only  such  effort  that  can 
be  reduced  or  will  not  be  incurred  if  the  data  item  is  eliminated.  If  the  data  arc  government  peculiar,  include 
the  efforts  for  acquiring,  writing,  assembling,  reproducing,  packaging  and  shipping.  It  also  includes  the  effort 
for  ;  nsfonning  into  government  format  with  reproduction  and  shipment  if  data  are  identical  to  that  used  by  the 
contractor,  but  m  a  different  format. 

30.5.1  Technical  Publications.  The  technical  publications  element  is  defined  as  todmical  data  which  provides 
instructions  for  the  installation,  operation,  maintenance,  training,  and  support  of  a  system  or  equipment  which  is 
formatted  into  a  technical  manual.  A  technical  manual  normally  indudes  operation  and  maintenance 
instructions,  parts  lists  or  parts  breakdown,  and  related  technical  information  or  procedures  exclusive  of 
administrative  procedures.  This  data  may  be  presented  in  any  form  (regardless  of  the  form  or  method  of 
recording).  Technical  orders  that  meet  the  criteria  of  this  definition  may  also  be  classified  as  technical  manuals. 
This  element  includes  the  data  item  descriptions  set  forth  in  categories  selected  from  the  DoD  5010. 12-L. 
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For  ships  include  Extended  Ship  Work  Breakdown  Structure  (ESWBS)  ILS  Engineering.  Technical 
Manuals  and  Other  Data  (856)  element. 

30.5.2  Fnptrw-rtni;  pat^  The  engineering  data  element  is  defined  as  recorded  information  (regaedlau  of  the 
form  or  method  of  recording)  of  a  scjenrific  or  technical  nature  (including  computer  toftware  documentation). 
Engineering  data  does  not  include  computer  software  or  financial,  administrative,  cost  or  pricing,  or 
management  Aar*  or  other  information  incidental  to  contract  administration. 

a.  Engineering  data  is  required  to  define  and  document  an  engineering  design  or  product  configuration 
(sufficient  to  allow  duplication  of  the  original  items)  and  is  used  to  support  production,  engineering  and  logistics 
activities.  This  dement  includes,  for  example,  ail  final  plans,  procedures,  reports,  and  documentation 
pertaining  to  systems,  subsystems,  computer  and  computer  resource  programs,  component  engineering, 
operational  testing,  human  fitters,  reliability,  availability,  and  maintainability,  and  other  engineering  analysis, 
etc. 


b.  A  data  package  (reprocuremcat  package)  includes  all  engineering  drawings,  associated 

lists,  process  descriptions,  and  other  documents  which  define  the  physical  geometry,  material  composition, 
performance  procedures. 

This  element  excludes  the  LSAR  and  support  data  delivered  under  30.5.4  of  this  section. 

For  ships  include  Extended  Ship  Work  Breakdown  Structure  (ESWBS)  Design  Support,  Ship's  Selected 
Records  (8302);  Design  Support,  Services,  Reproduction  (8303);  and  ILS  Engineering,  Engineering  Drawings 
and  Specifications  (855)  demenu. 

30.5.3  Ma/nwctnem  Data.  The  management  data  element  is  defined  as  those  data  items  necesmy  for 
configuration  management,  cost,  schedule,  contractual  data  management,  program  management,  etc.,  required 
by  the  gevenitucul  in  accordance  with  functional  categories  selected  from  the  uODi$$  and  DoD  5010. 12-L. 
This  element  includes  contractor  cost  reports,  cost  performance  reports,  contractor  fund  status  reports, 
schedules,  milestones,  networks,  integrated  support  plans,  etc. 

For  ships  include  Extended  Ship  Work  Breakdown  Structure  (ESWBS)  Contract  Data  Requirements 
(988)  dement. 

30.5.4  Support  Data.  The  support  data  element  defined  as  those  data  items  designed  to  document  the 
support  planning  in  accordance  with  functional  categories  selected  from  DoD  5010. 12-L.  This  element 
includes,  for  example,  LSA  documentation  and  LSA  record  maintenance  and  ddivery,  supply,  geacrel 
maintenance  plans  and  reports,  training  data,  transportation,  handling,  packaging  information,  facilities  data, 
data  to  support  the  provisioning  process  and  ail  other  support  data,  and  software  supportability  planning  and 
software  support  transition  planning  documents. 

30.5.5  Data  Depository.  The  data  depository  dement  is  defined  as  a  facility  designated  to  act  as  custodian  in 
establishing  and  maintaining  *  mauler  engineering  specification  and  drawing  depository  service  for  government 
approved  documents  that  are  the  property  of  the  U.S.  Government.  This  dement  represents  a  distinct  entity  of 
its  own  and  includes  all  effort  of  drafting,  clerical,  filing,  etc.,  required  to  provide  the  service.  As  custodian 
for  the  government,  the  contractor  is  authorized  by  approved  change  orders  to  maintain  these  master  documents 
at  the  latest  approved  revision  level.  When  documentation  is  called  for  on  a  given  item  of  data  retained  in  the 
depository,  the  charges  (if  charged  as  direct)  will  be  to  the  appropriate  data  element.  All  similar  effort  for  the 
contractor’s  internal  specification  and  drawing  control  system,  in  support  of  its  engineering  and  production 
activities,  is  excluded. 
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30.6  Peculiar  Support  Ecru  iron  ent.  The  peculiar  support  equipment  element  is  defined  to  include  the  design, 
development,  and  production  of  those  deliverable  items  and  associated  software  required  to  support  and  main  tain 
the  system  or  portions  of  the  system  while  cot  directly  engaged  in  the  performance  of  its  mission,  and  which 
have  application  peculiar  to  a  given  defense  materiel  item.  This  element  includes,  for  example,  vehicles, 
equipment,  tools,  etc.,  used  to  foci,  service,  transport,  hoist,  repair,  overhaul,  assemble,  disassemble,  test, 
inspect,  or  otherwise  maintain  the  mission  equipment.  It  also  includes  any  production  of  duplicate  or  modified 
factory  test  or  tooling  equipment  delivered  to  the  government  for  use  in  maintaining  the  system  (factory  test  and 
tooling  equipment  initially  used  by  the  contractor  in  the  production  process  but  subsequently  delivered  to  the 
government  will  be  included  as  cost  of  the  item  produced).  It  also  includes  any  additional  equipment  or 
software  that  will  be  required  to  maintain  or  modify  the  software  portions  of  the  system.  This  element  and  its 
subelements  specifically  exclude  the  overall  planning,  management  and  task  analysis  functions  inherent  in  the 
work  breakdown  structure  element  systems  engioeering/program  management,  and  the  common  support 
equipment  presently  in  the  BoD  inventory  or  commercially  common  within  the  industry  which  is  bought  by  the 
using  command  and  not  by  the  acquiring  command. 

30.6.1  Tea  and  Measurement  Bauinroent.  The  tea  and  measurement  equipment  element  is  defined  as  peculiar 
or  unique  resting  and  measurement  equipment  which  allows  an  operator  or  maintenance  function  to  er/ahute 
operational  conditions  of  a  system  or  equipment  by  performing  specific  diagnostics,  screening  or  quality 
assurance  effort  at  an  organizational,  intermediate,  or  depot  level  of  equipment  support.  It  includes  test 
measurement  and  diagnostic  equipment,  precision  measuring  equipment,  automatic  test  equipment,  manual  test 
equipment,  automatic  test  systems,  test  program  sets,  appropriate  interconnect  devices,  automated  load  modules, 
tap{s),  and  related  software,  firmware  and  support  hardware  (power  supply  equipment,  etc.)  used  at  all  levels  of 
maintenance.  It  includes  packages  which  enable  a  line  or  shop  replaceable  unit,  printed  circuit  boards,  or 
similar  items  to  be  diagnosed  using  automatic  test  equipment. 

30.6.2  Support  and  Handling  Equipment.  The  support  and  handling  equipment  dement  is  defined  as  the 
deliverable  tools  and  handling  equipment  used  for  support  of  the  mission  system.  !t  typically  includes  ground 
support  equipment,  vehicular  support  equipment,  powered  support  equipment,  uonpowered  support  equipment, 
munitions  material  handling  equipment,  materiel  handling  equipment,  and  software  support  equipment 
(hardware/software) . 

30.7  Common  Support  Equipment.  The  common  support  equipment  element  refers  to  those  items  required  to 
support  and  mainnin  the  system  or  portions  of  the  system  while  not  directly  engaged  in  the  performance  of  its 
mission,  and  which  are  presently  in  the  DoD  inventory  for  support  of  other  systems.  This  dement  includes  all 
efforts  required  to  assure  the  availability  of  this  equipment  for  support  of  the  particular  defense  materid  item. 

It  also  includes  the  acquisition  of  additional  quantities  of  this  equipment  if  caused  by  the  introduction  of  the 
defense  materiel  item  into  operational  service. 

30.7.1  Test  and  Nfcasurcromt  Equipment.  The  test  and  measurement  equipment  element  is  defined  as  common 
testing  and  measurement  equipment  which  allows  an  operator  or  maintenance  function  to  evaluate  operational 
conditions  of  a  system  or  equipment  by  performing  specific  diagnostics,  screening  or  quality  assurance  effort  at 
an  organizational,  intermediate,  or  depot  level  of  equipment  support.  It  includes  test  measurement  and 
diagnostic  equipment,  precisian  measuring  equipment,  automatic  test  equipment,  manual  test  equipment, 
automatic  teat  systems,  test  program  sets,  appropriate  interconnect  devices,  automated  load  modules,  tap(t>,  and 
related  software,  firmware  and  support  hardware  (power  supply  equipment,  etc.)  used  at  all  levels  of 
maintenance.  It  includes  packages  which  enable  a  line  or  shop  replaceable  unit,  primed  circuit  boards,  or 
similar  items  to  be  diagnosed  using  automatic  test  equipment. 

30.7.2  Support  and  Handling  Equipment.  The  support  and  handling  equipment  element  is  defined  as  the 
deliverable  tools  and  handling  equipment  used  for  support  of  the  mission  system.  It  typically  includes  ground 
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support  equipment,  vehicular  support  equipment,  powered  support  equipment,  nonpowered  support  equipment, 
munitions  materia]  handling  equipment,  materiel  handling  equipment,  and  software  support  equipment 
(hardware/software) . 

30.8  Operational /Site  Activation.  The  operational/site  activation  element  refers  to  die  real  estate,  construction, 
conversion,  utilities,  and  equipment  to  provide  all  facilities  required  to  house,  service,  and  launch  prime  mission 
equipment  at  the  organizations!  and  intermediate  level.  This  element  includes  conversion  of  site,  ship,  or 
vehicle;  system  assembly,  checkout,  and  installation  (of  mission  and  support  equipment)  into  she  facility  or  ship 
to  achieve  operational  status.  It  also  includes  contractor  support  in  relation  to  operational/site  activation. 

30.8.1  System  Assembly.  Installation,  and  Checkout  on  Site.  The  system  assembly,  installation,  and  checkout 
on  site  element  refers  to  the  materials  and  services  involved  in  the  assembly  of  mission  equipment  at  the  site. 
This  element  includes,  for  example,  installation  of  mission  and  support  equipment  in  the  operations  or  support 
facilities  and  the  complete  system  checkout  or  shakedown  to  insure  achievement  of  operational  status.  Where 
appropriate,  specify  by  site,  ship  or  vehicle. 

30.8.2  Contractor  Technical  Support.  The  contractor  technical  support  element  refers  to  all  materials  and 
set vices  provided  by  the  contractor  related  to  activation.  This  element  includes  repair  of  reparables,  standby 
services,  final  turnover,  etc. 

30.8.3  Site  Construction.  The  site  construction  element  refers  to  the  real  estate,  site  planning/prepanuion, 
construction,  and  other  special-purpose  facilities  necessary  to  achieve  sy  stem  operational  status.  This  element 
also  includes  the  construction  of  utilities,  roads,  and  interconnecting  cabling. 

30.8.4  Site/Ship/Vehicle  Conversion.  The  site/ship/vehicle  conversion  element  refers  to  all  materials  and 
services  required  to  provide  for  the  conversion  of  existing  sites,  ships,  or  vehicles  to  accommodate  the  mission 
equipment  and  selected  support  equipment  directly  related  to  the  specific  system.  This  ClCIIiwjut  includes 
operations,  support,  and  other  special  purpose  (c.g.,  launch)  facilities  conversion  necessary  to  achieve  system 
operational  status.  Where  appropriate,  specify  by  site,  ship,  or  vehicle. 

30.9  Industrial  Facilities.  The  industrial  facilities  dement  refers  to  the  construction,  conversion,  or  expansion 
of  industrial  facilities  for  production,  inventory,  and  contractor  depot  maintenance  required  when  that  service  is 
for  the  specific  system.  This  element  includes,  for  example,  equipment  acquisition  or  modernization,  where 
applicable,  and  maintenance  of  these  facilities  or  equipment.  This  dement  also  includes  industrial  facilities  for 
hazardous  waste  management  to  satisfy  environmental  standards. 

30.9. 1  Construction/Conversion/Expansion.  The  consmiction/conversion/expansic  i  element  refers  to  the  real 
estate  and  preparation  of  system  peculiar  industrial  facilities  for  production,  inventory,  depot  maintenance,  and 
other  related  activities. 

30.9.2  Fimipment  Acquisition  or  Modernization.  The  equipment  acquisition  or  modernization  element  refers  to 
production  equipment  acquisition,  modernization,  or  transferal  of  equipment  for  the  particular  system.  (Pertains 
to  government  owned  and  leased  equipment  under  facilities  contract.) 

30.9.3  Maintenance  (lndu&trial  Facilities).  The  maintenance  (industrial  facilities)  element  refers  to  the 
maintenance,  preservation,  and  repair  of  industrial  facilities  and  equipment. 

30.10  Initial  Spares  and  Repair  Parts,  Initial  spares  and  repair  parts  element  is  defined  as  the  deliverable  spare 
components,  assemblies  and  subassemblies  used  for  initial  replacement  purposes  in  the  materiel  system 
equipment  end  item.  This  element  mcludes  the  repairable  spares  and  repair  pans  required  as  initial  stockage  io 
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support  ««*  ttaimain  newly  fielded  systems  or  subsystems  (luring  ibe  initial  phase  of  service,  ladading  pipeline 
rad  war  reserve  quantities,  at  ail  levels  of  toxin  ten  sure  and  support.  This  excludes.  ^cvelopraeM  test 

spares  and  spares  provided  specifically  for  use  during  installation,  assembly  and  checkout  on  site.  The  lower 
level  WBS  breakouts  should  be  by  subsystem. 
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APPENDIX  I 
USER  GUIDE 


10.  SCOPE 

10. 1  This  appendix  presents  a  User  Guide  for  preparing,  understanding  and  presenting  a  work  breakdown 
structure  (WBS).  The  guide  discusses  the  requirement  for  a  work  breakdown  structure,  provides  a  general 
understanding  for  developing  a  program  work  breakdown  structure,  shows  how  to  develop  and  impta&an  a 
contract  work  breakdown  structure,  and  presents  examples  of  work  breakdown  structures  for  various 
applications.  The  primary  objective  of  this  guide  is  to  achieve  a  consistent  application  of  the  work  breakdown 
structure.  This  appendix  is  not  s  mandatory  part  of  the  standard.  Hie  information  contained  herein  is  intended 
for  guklsnce  only. 

10.2  The  foundation  for  the  .  •xpiircmmt  and  dc'clt'ornc'C  of  thi  work  breakdown  structure  is  described  in 
DoDD  5000.1,  DoDI  5000.2,  a.'d  DoD  5000.2-M.  These  documents  identify  responsibilities  in  the  acquisition 
process  from  the  Office  of  the  Secretary  of  Defense  to  the  DoD  CoLyonent  field  activities.  The  requirement  to 
prepare  a  work  breakdown  structure  is  generally  discussed  in  the  contex*  of  planning  and  monitoring  a  defense 
materiel  system  program. 

10.3  This  guide  is  directed  primarily  at  the  prepaid  on  of  a  work  breakdown  struct  ire  for  a  defense  materiel 
item.  This  includes  all  defense  materiel  items  (or  major  modifications)  (a)  established  a.  an  integral  program 
element  of  the  Future  Years  Defense  Program  (FYDP);  or  (b)  otherwise  designated  by  foe  DoD  Component  or 
the  Under  Secretary  of  Defense  (Acquisition). 

10.3.1  The  guidance  is  also  appropriate  for  u*c  with  any  w.  ric  breakdown  structure  Q'vJ<nrct  u  any  phase 
during  the  acquisition  process,  including  concept  exploration  vkI  definition,  demonstration  .  id  validation, 
engineering  and  manufacturing  development,  and  production. 

10.3.2  This  guide  provides  the  framework  for  preparing  a  complete  work  oreaknown  structure,  fh  guidelines 
are  directed  at  both  contractors  and  DoD  Components  (Government  activities)  in  the  development  of  w.'rk 
breakdown  structures  for  the  acquisition  of  defense  materiel  items. 

20.  APPLICABLE  DOCUMENTS 

20.1  Government  Documents. 

20.1.1  Specifications,  Standards,  and  Handbooks.  The  following  specifications,  standards,  and  handbooks 
form  a  part  of  this  document  to  the  exbait  specified  herein.  Unless  otherwise  specified,  the  issues  of  these 
documents  are  those  listed  in  the  issue  of  the  Department  of  Lefense  Index  of  Specifications  (DODISS)  and 
supplement  thereto,  cited  in  the  solicitation. 

STANDARDS 

MIL-STD-196  Joint  Electronics  Type  Designation  System 


DOD-STD-2167 


Defense  System  Software  Development 
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(Unless  otherwise  indicated,  copies  of  federal  and  military  specifications,  standards,  and  handbooks  arc  available 
from  the  Standardization  Documents  Order  Desk,  700  Robbins  Avenue,  Building  #4,  Section  D,  Philadelphia, 
PA  19111-5094.) 


20. 1 .2  Other  Government  Document;,  Drawings,  and  Publications.  The  following  other  Government 
document*,  drawings,  and  publications  form  a  part  of  ihk  document  to  the  extern  specified  herein.  Unless 
otherwise  specified,  tfct  issues  arc  those  cited  in  the  solicitation. 


PAMPHLETS 


Contractor  Cost  Daa  Reporting  (CCDR) 


NAVMAT  P-5241 
AMC-P  715-S 
AJFLCP  800-15 
AFSCP  800-15 


Navy  Materiel  Command  Pamphlet 
Army  Materiel  Command  Pamphlet 
Air  Force  Logistics  Command  Pamphlet 
Air  Force  Systems  Command  Pamphlet 


Cost/Schedule  Control  System  Criteria  Joint  Implementation  Guide 


NAVSO  P3627 
AFSCP  173-5 
AFCCP  173-5 
AFLCP  173-5 
AMC-P  715-5 
DLAH  8400.2 
DCAA  P7641.47 


Assistant  Secretary  of  the  Navy  (S&L)  Pamphlet 
Air  Force  Systems  Command  Pamphlet 
Air  Force  Communications  Command  Pamphlet 
Air  Force  Logistics  Command  Pamphlet 
Army  Materiel  Command  Tarophkt 
Defense  Logistics  Agency  Handbook 
Defense  Contract  Audit  Agency  Pamphlet 


(The  above  pamphlet  numbers  identify  two  single  rfcctiir«r<M».  Cumnnor  Cost  Data  Reporting  (CCDR)  System 
(Stock  Number  0518LP1003001),  and  Cost/Schedule  Control  System  Criteria  Joint  Implementation  Guide 
(Stock  Number  0518LP1002010).  These  two  documents  can  be  ordered  by  stock  number  from  ’he 
Standardization  Documents  Order  Desk,  700  Robbins  Avenue,  Building  #4,  Section  D,  Philadelphia.  PA  19111- 
5094.) 


20.2  Non-Govcmment  Publications.  This  section  is  not  applicable  to  this  standard. 


30.  DEFINITIONS 


30. 1  Program  Work  Breakdown  Structure.  A  program  work  breakdown  structure  is  definec  as  the  work 
breakdown  structure  that  covers  the  acquisition  of  a  specific  defense  materiel  item  and  is  related  to  contractual 
effort.  A  program  work  breakdown  structure  includes  all  applicable  elements  consisting  of  at  least  the  first 
three  levels  of  the  work  breakdown  structure  and  extrtndod  by  the  DoD  Component  (program  manager)  and/or 
contractors).  A  program  work  breakdown  structure  has  uniform  element  terminology,  definition,  ead 
placement  in  the  family  tree  structure. 

Level  1:  Level  1  is  the  entire  defense  materiel  item;  for  example,  an  aircraft  system,  such  as  a  helicopter, 
bomber,  transport  aircraft,  fighter  aircraft  or  reconnaissance  aircraft.  Level  1  is  usually  directly  identified  in 
the  DoD  prograinming/budget  system  either  as  an  integral  program  element  or  as  a  project  or  subprogram 
within  an  aggregated  program  element. 
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Level  2:  Level  2  elements  are  major  elements  of  the  defense  mr  riel  item;  for  example,  air  vehicle 
which  includes  all  hardware  and  software  elements,  aggregations  of  system  level  services  (e.g.,  system  test  and 
evaluation,  and  systems  engineering/program  management)  and  data. 

Level  3:  Level  3  elements  are  elements  subordinate  to  level  2  major  elements;  for  example,  propulsion, 
fire  control,  navigation  guidance,  armament,  or  type  of  service  (e.g.,  development  test  and  evaluation, 
contractor  technical  support,  training  services),  or  types  of  data  (e.g.,  technical  publications).  Lower  levels 
follow  the  same  process. 

30.2  Contract  Wprk,  ^pealcdown  Structure.  A  contract  work  breakdown  structure  is  defined  as  the  complete 
work  breakdown  structure  for  a  contract,  it  includes  the  DoD  approved  work  breakdown  structure  for.  reporting 
purposes  and  its  discretionary  extension  to  the  lower  levels  by  the  contractor,  in  accordance  with  this  standard, 
and  die  contract  work  statement.  It  includes  all  the  elements  for  the  products  (hardware,  software,  data,  or 
services)  which  are  the  responsibility  of  the  contractor. 

40.  BACKGROUND 

40. 1  Purpose.  When  the  decision  is  made  to  develop  and  acquire  a  new  or  updated  system,  several  factors  are 
considered  when  planning  or  monitoring  efforts.  One  of  these  factors  is  determining  the  work  breakdown 
stracTTe  to  use  for  die  system.  A  work  breakdown  structure  is  a  product-oriented  family  tree,  composed  of 
hardware,  software,  services,  data  and  facilities,  which  tesulte  from  systems  engineering  efforts  during  the 
development  and  production  of  a  defense  materiel  item,  and  which  completely  defines  the  program.  A  work 
breakdown  structure  displays  and  defines  the  product(s)  to  be  developed  or  produced  and  relates  the  elements  of 
work  to  be  accomplished  to  each  other  and  to  the  end  product.  Therefore,  the  work  breakdown  structure  plays 
a  significant  role  in  planning  and  aligning  management  and  technical  responsibilities  and  in  monitoring  and 
controlling  the  progress  and  status  of  engineering  efforts,  resource  allocations,  cost  estimates,  expenditures,  and 
cost  and  technical  performance. 

40.2  Work  Breakdown  Structure  Applications.  The  work  breakdown  structure  provides  a  framework  for 
specifying  the  objectives  of  the  program  by  first  defining  the  program  in  terms  of  hierarchically  related  product- 
oriented  elements  and  the  work  processes  required  for  their  completion.  Each  element  of  the  work  breakdown 
structure  provides  logical  summary  points  for  assessing  technical  accomplishments  and  for  measuring  the  cost 
and  schedule  performance  accomplished  in  attaining  the  specified  technical  objectives. 

For  each  work  breakdown  structure  element,  the  detailed  objectives  are  defined  as  well  as  the  specific  work 
tasks  assigned  to  e^,j  contractor  organization  dement  and  the  resources,  materials,  and  processes  required  to 
attain  the  objectives.  As  resources  are  employed  and  work  progresses  on  the  task,  current  technical ,  schedule, 
cost,  and  estimate  at  completion  data  are  reported.  The  data  may  then  be  summarized  to  provide  successive 
levels  of  management  with  the  appropriate  report  on  planned,  actual,  and  current  projected  status  of  the 
elements  for  which  they  are  responsible.  Management  will  thus  be  better  able  to  maintain  visibility  of  status 
and  to  apply  efforts  to  assure  desired  performance. 

40.2.1  Technical  Management.  The  work  breakdown  structure  provides  a  framework  for  defining  the  technical 
objectives  of  the  program.  Together  with  the  contract  statement  of  work,  the  work  breakdown  structure  aids  in 
establishing  an  indentured  data  listing  (specification  tree),  defining  configuration  items,  and  planning  support 
tasks. 

40.2 . 1 . 1  Contract  Statement  of  Work.  The  statement  of  work  (SOW)  is  the  document  which  describes  in  clear 
understandable  terms  what  products  are  to  be  delivered  or  services  to  be  performed  by  the  contractor. 
Preparation  of  an  effective  SOW  requires  an  understanding  of  the  products  and  services  that  are  needed  to 
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satisfy  a  particular  requirement.  A  SOW  prepared  in  explicit  terms  will  facilitate  effective  contractor  evaluation 
after  contract  award.  The  SOW  becomes  the  standard  for  measuring  contractor  performance.  Therefore,  the 
SOW  must  clearly  define  the  work  to  be  performed,  in  preparing  the  SOW  for  a  system  acquisition,  the  use  of 
a  standardized  work  breakdown  structure  as  a  template  for  constructing  the  SOW  will  help  streamline  the 
process.  Use  of  the  work  breakdown  structure  will  also  provide  the  framework  and  facilitate  a  logical 
arrangement  of  the  SOW  dementi,  provide  a  convenient  checklist  to  ensure  all  necessary  dementi  of  the 
program  are  addressed,  and  direct  the  contractor  to  meet  specific  contract  repotting  needs. 

40.2.1.2  Data  Listing.  An  indentured  dan  listing  (specification  tree),  developed  by  systems 
mgiiwring  structures  the  performance  parameters  for  the  system  or  systems  being  developed,  it  subdivides 
foeaystemfa)  into  itsoompoDeat  element*  and  identifies  the  performance  objectives  of  the  system?*)  and  its  ele¬ 
ments.  The  performance  characteristics  are  explicitly  identified  and  quantified.  Completed,  the  indentured  data 
listing  reprcaents  a  hierarchy  of  performance  requirements  for  each  component  dement  of  the  system  for  which 
design  responsibility  is  assigned.  Because  specifications  may  not  be  writtsi  for  each  product  on  the  work 
breakdown  structure,  the  indentured  data  listing  may  not  match  the  work  breakdown  structure  completely. 

40.2.1.3  Configuration  Management.  Configuration  management  is  the  process  of  managing  the  technical 
configuration  of  items  being  developed  whose  requirements  must  be  specified  and  controlled  (ref.  MIL- STD- 
973).  in  establishing  the  requirement  for  configuration  management  on  a  program,  the  DoD  Component  needs 
to  designate  which  contract  deliverables  are  subject  to  configuration  management  controls.  A  contract 
deliverable  designate!  for  configuration  management  is  called  a  Configuration  Item.  For  software,  this  item  is 
called  a  computer  software  configuration  item  (CSCI).  Configuration  management  involves  defining  the 
baseline  configuration  for  the  configuration  items,  ctm trolling  the  changes  to  that  baseline,  and  accounting  for  all 
approved  changes.  The  framework  for  designating  foe  configuration  items  on  a  program  is  the  work  breakdown 
structure  which  needs  to  be  extended  sufficiently  to  clearly  define  ail  elements  subject  to  configuration 
management. 

40.2.2  Financial  Management,  The  work  breakdown  structure  assists  management  in  measuring  cost  and 
schedule  performance.  By  breaking  die  total  product  into  successively  smaller  entities,  management  can  ensure 
that  all  required  products  are  identified  in  terms  of  cost  and  schedule  performance  goals.  The  planning  of  work 
by  work  breakdown  structure  elements  serves  as  the  basis  for  estimating  and  scheduling  resource  requirements. 
The  assignment  of  performance  budgets  to  scheduled  segments  of  contract  work  and  identified  to  responsible 
organization  units  produces  a  time  phased  plan  against  winch  actual  performance  am  be  compared  and 
appropriate  corrective  action  taken  when  deviations  from  plan  are  identified.  This  integrated  approach  to  work 
planning  also  simplifies  the  identification  of  potential  coat  and  schedule  impacts  of  proponed  technical  changes. 

40.2.2. 1  Contract  Budgeting.  Funds  management  involves  periodic  comparison  of  actual  costs  with  time 
phased  budgets,  analysis  of  performance  variances,  and  follow-up  corrective  action,  as  required.  When  work 
breakdown  structure  product  elements  and  the  supporting  work  are  scheduled,  a  solid  base  for  time  phased 
budgets  is  nude.  Assignment  of  planned  resource  cost  estimates  to  scheduled  activities  (tasks)  and 
summarization  by  work  breakdown  structure  element  by  time  period  results  in  a  time  phased  program/ contract 
budget,  which  becomes  the  performance  measurement  baseline. 

40.2.2.2  Cost  Estimating.  Use  of  the  work  breakdown  structure  for  cost  estimating  facilitates  program  and 
contract  management.  The  work  breakdown  structure  aids  the  DoD  program  office  to  plan,  coordinate,  control, 
and  estimate  foe  various  program  activities  that  DoD  and  the  contractors  are  conducting.  It  provides  a  common 
framework  for  tracking  the  estimated  and  actual  costs  during  the  performance  of  each  contract.  The  data  from 
the  various  program  contracts  support  the  DoD  program  manager  in  evaluating  contractor  performance, 
preparing  budgets,  and  preparing  program  life-cycle  costs,  e.g.,  as  programs  move  through  the  various  phases 


14 


MIL-STD-881B 

of  the  acquisition  process  (conceptual  design,  development,  and  production)  the  actual  experience  to  date  and  the 
estimates  for  the  remaining  phases  provide  the  basis  for  reassessment  of  the  total  program  costs. 

40.2.2.3  Data  Bases.  Cost  information  collected  by  work  breakdown  structure  clement  can  be  used  for  pricing 
and  negotiating  contracts  and  contract  changes,  and  for  follow-on  procurement.  DoD  is  accumulating  a  growing 
cost  data  base  of  similar  work  breakdown  structure  elements  from  different  programs.  Such  historical  cost  data 
can  be  used  to  develop  learning  curves  and  for  regression  analysis  and  other  technique  to  estimate  the  cost 
requirements  for  like  elements  of  new  programs.  Actual  cost  data  collected  by  DoD  o  each  program  can  be 
compared  to  the  original  estimates  to  identify  trends  and  to  establish  the  validity  of  es  -rating  techniques. 
Contractors  will  similarly  benefit  from  such  data  bases.  Since  contractors  tend  to  provide  similar  products  on 
similar  programs,  the  cost  history  accumulated  on  their  programs  can  assist  them  in  estimating  and  bidding 
future  contracts  and  budgeting  new  work. 

40.3  Relationship  to  Other  Contract  Requirements.  The  work  breakdown  structure  is  the  basis  for 
communication  throughout  tbe  acquisition  process,  it  provides  the  common  link  unifying  the  planning, 
scheduling,  cost  estimating,  budgeting,  contracting,  configuration  management,  and  performance  reporting 
disciplines.  The  structure  and  definitions  contained  in  this  standard  will  be  the  basis  for  structures  used  for 
contracts  requiring  compliance  with  the  Cost/Schedule  Control  Systems  Criteria  (C/SCSC),  and  reports  placed 
on  contract  such  as  Contractor  Cost  Data  Reporting  (CCDR),  Cost  Performance  Reports  (CPR),  Contract  Funds 
Status  Reports  (CFSR),  and  Cost/Schedule  Status  Reports  (C/SSR).  This  capability  permits  the  contractor  to 
evaluate  progress  in  terms  of  contract  performance.  Consult  the  referenced  documents  for  program  applicability 
and  specific  requirements  per  paragraph  20.1.2  in  this  appendix. 

50.  DETAILED  REQUIREMENTS 

50.1  Scope.  Work  is  effort  performed  by  people  to  transferal  or  create  products  to  solve  identified  problems 
in  order  to  verifiably  meet  specified  objectives.  Just  as  the  organizational  structure  hierarchically  structures  the 
people  who  perform  work,  so  the  work  breakdown  structure  hierarchically  structures  the  products  to  be 
produced  on  which  the  people  work.  Examples  of  these  products  include  equipment  (hardware/software),  data, 
services  and  facilities  for  such  systems  as  missile  systems,  helicopter  systems,  automated  software  systems,  etc. 

Work  breakdown  structure  elements  depict  products  in  a  manner  in  which  technical  accomplishment  can  be 
incrementally  verified  and  measured  and  provide  the  conceptual  framework  for  integrated  planning  and  control 
of  the  work.  For  example,  program  management  benefits  all  hardware,  software,  and  data  products  in 
indeterminable  proportion.  From  a  management  control  perspective,  such  work  is  essentially  indirect  to  the 
hardware,  software,  and  data  products,  but  direct  to  the  contract  or  program.  As  a  result,  when  program 
management  is  separately  identified  within  the  framework  of  the  work  breakdown  structure,  the  work  performed 
can  be  verified  and  measured.  It  is  for  these  reasons  that  the  work  breakdown  structure  is  a  valuable  tool. 

50.2  Purpose.  The  development  of  any  work  breakdown  structure  is  intended  to  achieve  a  clear  understanding 
and  statement  of  the  technical  objectives  and  the  end  item(s)  (or  end  product(s))  of  the  work  to  be  performed. 
The  process  of  identifying  these  objectives  assists  in  structuring  the  product  elements  during  the  work 
breakdown  structure  development.  Objectives  derived  from  the  overall  program  objective  are  identified  in  such 
a  way  that  products  support  economically  and  technically  identifiable  subsystems  of  the  program  objectives. 

This  process  may  be  repeated  until  the  component  level  is  reached.  In  this  manner,  subsystems  support  a  total 
system  capability. 

In  order  to  use  the  work  breakdown  structure  as  a  framework  for  structuring  the  technical  objectives  of  a 
program,  in  addition  to  its  use  as  a  management  tool  for  cost  and  schedule  control,  it  is  important  that  the  work 
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breakdown  structure  be  product  oriented.  Its  elements  should  represent  identifiable  work  products  whe'her  they 
be  equipment  (hardware/software),  data  or  relatable  service  products.  Because  any  work  breakdown  structure  is 
a  product  structure,  not  an  organization  structure,  complete  definition  of  the  effort  encompasses  the  work  to  be 
performed  by  all  participants. 

50.3  Acquisition  Process.  The  work  breakdown  structure  is  developed  during  the  acquisition  process  of  a 
defense  materiel  item.  Government  and  industry  view  this  process  from  different  perspectives,  but  the  ultimate 
objective  is  consistent.  Figure  1-1  provides  an  overview  of  the  work  breakdown  structure  development  process. 
The  DoD  acquisition  process  is  where  this  standard  is  utilized.  Figures  1-2  and  1-3  depict  the  overall  process 
from  both  the  DoD  and  industry  perspective  and  how  the  WBS  flow  relates  to  this  process. 

50.4  Preparing  a  Program  Work  Breakdown  Structure.  The  DoD  program  rnanagu'  is  responsible  for 
developing  and  maintaining  the  program  work  breakdown  structure.  The  DoD  program  manager  will  structure 
a  program  work  breakdown  structure  for  a  defense  materiel  item  prior  to  program  initiation  by  selecting 
appropriate  elements  from  one  or  more  of  the  work  breakdown  structure^)  set  forth  in  appendices  A  through  G. 
The  result  will  initially  map  the  program  work  breakdown  structure.  Although  the  appendices  .'elate  to  specific 
categories  of  defense  materiel  items,  any  item  from  any  appendix  may  be  used  which  is  applicable  to  the 
program,  as  long  as  the  integrity  of  the  level  of  placement  is  maintained. 

50.4.1.  Develop  Program  Work  Breakdown  Structure.  The  program  work  breakdown  structure  should  be 
developed  early  in  the  conceptual  stages  of  the  program  and  be  based  initially  on  the  work  breakdown  structure* 
identified  in  appendices  A  through  G.  The  program  work  breakdown  structure  evolves  during  conceptual  design 
from  an  iterative  analysis  of  the  program  objective,  functional  design  criteria,  program  scope,  technical 
performance  requirements,  proposed  methods  of  raformance,  including  acquisition  strategy,  as  well  as 
drawings,  process  flow  chans,  and  other  technical  documentation.  It  is  important  the  documentation  describe 
the  DoD  plan  to  build,  integrate,  and  field  the  system.  The  Cost  Analysis  Requirements  Document  (CARD) 
will  be  the  recording  document  for  this  program  plan.  Ultimately ,  the  program  work  breakdown  structure  must 
be  approved  through  the  CCDR  plan  process.  Through  this  process,  the  levels  of  reporting  anti  elements  for 
appropriate  RFP  selection  are  determined. 

50.4  .2  Program  Work  Breakdown  Structure  Element  Selection  Requirements.  The  program  work  breakdown 
structure  elements  must  be  selected  by  rbc  DoD  Component  and  be  structured  in  such  a  way  that  products  and 
services  may  be  readily  summarized  ir.io  the  program  work  breakdown  structure.  The  program  work 
breakdown  structure  and  contract  work  breakdown  structure  extensions  will  be  used  as  a  framework  for 
technical  and  management  activities.  The  DoD  Component  will  employ  the  program  work  breakdown  structure 
and  its  contract  work  breakdown  structure  extensions  as  a  coordinating  medium  in  planning  for  further  systems 
engineering,  resource  allocution,  cost  estimates,  contract  actions,  and  work  execution.  The  reporting  of 
progress,  performance,  tmd  engineering  evaluations,  as  well  as  financial  data,  will  be  based  on  the  program 
work  breakdown  stmcture.  Figure  1-4  provides  an  example  of  a  top  level  program  work  breakdown  structure. 

50.4.3  Levels  of  Program  Work  Breakdown  Structure.  The  program  work  breakdown  structure  contains  the 
top  three  levels  expanded  to  identify  elements  with  a  significant  degree  of  technical  or  cost  risk.  When  program 
work  breakdown  structure  levels  are  stipulated  to  an  excessively  low  level  of  a  program,  the  contractor’s  normal 
method  of  operation  may  be  hampered,  or  excessive  reporting  requirements  may  result.  The  SOW  and  CDRLs 
arc  the  place  to  clearly  communicate  all  program  requirements.  Figure  1-5  provides  an  expanded  program  work 
breakdown  structure  which  incorporates  elements  necessary  for  contract  visibility  and  control.  This  program 
WBS  is  based  on  Appendix  A  and  uses  those  WBS  elements  applicable  to  the  system. 

50.4.4  Considerations  in  Constructing  a  WBS.  The  following  should  be  kept  in  mind  when  constructing  a 
work  breakdown  structure: 
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Figure  1-2.  DoD  PROCESS  FLOW 
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Figure  1-3.  INDUSTRY  PROCESS  FLOW 
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Figure  1-4.  TOp  T  '"VEL  PROGRAM  WORK  BREAKDOWN  STRUCTURE 
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Figure  1-5.  EXPANDED  PROGRAM  WORK  BREAKDOWN  STRUCTURE 
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a.  Many  elements  of  a  program  are  not  products.  A  signal  processor,  for  example,  is  clearly  a 
product,  as  are  mock-ups,  and  Computer  Software  Configuration  Items  (CSCis).  Design  engineering, 
requirements  analysis,  test  engineering  labor,  aluminum,  and  direct  costs,  etc.,  are  not  products.  Design 
engineering,  test  engineering,  and  requirements  analysis  are  all  engineering  functional  efforts;  aluminum  is  a 
material  resource;  and  direct  cost  is  an  accounting  classification.  As  such,  none  of  these  elements  are 
appropriate  as  work  breakdown  structure  elements  (ref.  Chapter  4  of  Contractor  Cost  Data  Reporting  (CCDR) 
System  for  functional  category  definitions). 

b.  Program  phases  (e.g.,  design,  development,  production),  and  types  of  funds  (e.g.,  Research, 
Development,  Test  and  Evaluation)  are  inappropriate  dements  of  a  work  breakdown  structure. 

c.  Rework,  retesting  and  refurbishing  should  be  treated  as  work  on  the  appropriate  work  breakdown 
structure  element  affected,  not  as  separate  elements  of  a  work  breakdown  structure. 

d.  Nonrecurring  and  recurring  classifications  are  not  work  breakdown  structure  elements.  The 
reporting  requirements  of  Contractor  Cost  Data  Reporting  (CCDR)  will  segregate  each  work  breakdown 
structure  element  into  its  nonrecurring  and  recurring  parts  (ref.  Chapter  4  of  Contractor  Cost  Data  Reporting 
(CCDR)  System). 

e.  Cost  saving  efforts  such  as  total  quality  management  initiatives,  could  cost,  wananty,  etc.,  are  not 
work  breakdown  structure  elements.  These  efforts  should  be  included  in  the  cost  of  the  item  they  affect  and  not 
capered  separately. 

f.  The  organizational  structure  of  the  program  office  or  the  contractor  should  not  be  the  basis  for 
development  of  a  work  breakdown  structure.  The  work  breakdown  structure  should  always  retain  its  product 
orientation. 

g.  Costs  for  meetings,  travel,  computer  support,  etc.,  are  to  be  included  with  the  work  breakdown 
structure  elements  for  which  they  are  associated.  They  are  not  to  be  treated  as  separate  work  breakdown 
structure  elements. 

h.  The  use  of  generic  terms  in  a  work  breakdown  structure  is  improper.  The  system(s)  name  and/or 
nomenclature  is  required.  The  woik  breakdown  structure  elements  should  be  clearly  named  to  indicate  the 
character  of  the  product  to  avoid  semantic  confusion.  For  example,  if  the  Level  1  system  is  Fire  Control,  then 
the  Level  2  item  (prime  mission  product)  is  Fire  Control  Radar.  The  name  or  nomenclature  for  the  electronic 
subsystem  should  be  developed  using  MIL-STD-196,  when  appropriate.  Figure  1-6  provides  a  reference  on  how 
to  use  MIL-STD-196  to  identify  the  nomenclature  for  electronic  systems. 

i.  Tooling  (e.g.,  special  test  equipment,  and  factory  support  equipment  such  as:  assembly  tools,  dies 
jigs,  futures,  master  forms,  handling  equipment,  etc.)  should  be  included  in  the  cost  of  the  equipment  being 
produced.  It  is  a  functional  cost  (ref.  CCDR  System,  Chapter  4)  not  a  work  breakdown  structure  element.  If 
the  tooling  cannot  be  assigned  to  an  identified  subsystem  or  component,  it  should  be  included  in  the  cost  of 
integration,  assembly,  test,  and  checkout.  Any  additional  quantities  produced  for  equipment  support  or 
maintenance  in  the  field  should  be  included  and  reported  under  Peculiar  Support  Equipment.  This  same 
philosophy  applies  to  software.  For  example,  when  a  software  development  facility  /environment  is  created  to 
support  the  development  of  software,  the  effort  associated  with  this  element  is  considered  pan  of  the  CSC  I  it 
supports;  or  if  more  than  one  CSCI  is  involved,  it  should  be  included  in  integration,  assembly,  test  and 
checkout. 
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Figure  1-6.  EXAMPLE  OF  TYPE  DESIGNATOR  FOR  ELECTRONIC  EQUIPMENT 
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j.  Software  that  is  being  developed  to  reside  on  specific  equipment  must  be  identified  as  a  subset  of 
that  equipment. 

k.  The  definition  of  integration,  assembly,  test,  and  checkout  is  on  page  H-2.  This  definition  should 
be  read  carefully  before  the  work  breakdown  structure  is  developed.  Note  tha-  integration,  assembly,  test,  and 
checkout  includes  production  acceptance  testing  (including  first  article  test)  of  R&D  and  production  units,  but 
excludes  all  systems  engineering  /pro  gram  management,  and  system  test  and  evaluation  which  are  associated  with 
the  overall  system.  Each  appendix  identifies  integration,  assembly,  test  and  checkout  separately  with  the 
exception  of  the  aircraft  system  appendix  (Appendix  A).  For  aircraft  systems,  the  integration,  assembly,  test, 
and  checkout  is  a  subelement  of  (and  included  in)  the  airframe  won*  breakdown  structure  clement  to  be 
consistent  with  the  historical  dr ta  •set:  that  arc  maintained  on  airframe. 

l.  This  standard  does  not  identify  Level  3  dements  for  the  systems  eng  inee  ring/pro  gram  management 
work  breakdown  structure  element.  This  allows  the  government  and  contractor  flexibility  to  identify  efforts  that 
are  important  to  the  specific  program.  The  definition  given  provides  typical  systems  engineering/program 
management  efforts. 

m.  System  test  and  evaluation  always  separately  identifies  those  tests  psrfotmed  in  the  development  of 
a  system  (i.e.,  development  test  and  evaluation),  and  those  tests  performed  by  the  operational  user  (i.e., 
operational  test  and  evaluation). 

Figure  1-7  provides  an  example  of  both  a  correct  and  an  incorrect  work  breakdown  structure. 

50.4.5  Software  in  the  Work  Breakdown  Structure.  This  standard  recognizes  the  importance  of  software  within 
the  DoD  environment.  Software  is  identified  in  each  appendix.  In  addition.  Appendix  B.  Electronic/ Automated 
Software  Systems,  describes  software  in  more  detail.  The  software  definitions  are  consistent  with  policies  and 
practices  discussed  in  DoD-STD-2167. , 

50.4.5.1  Contracts  with  Hardware/Software.  Software  that  is  being  developed  to  reside  on  specific  equipment 
must  be  identified  as  a  subset  of  that  equipment.  Multi-function  software  will  be  identified  as  a  substi  of  the 
equipment  work  breakdown  structure  element  which  either  includes  the  software  in  the  element  specification  or 
exercises  the  most  critical  performance  constraint.  Figure  1-8  provides  an  example  of  how  software  should  be 
addressed  as  part  of  a  specific  equipment.  In  cases  where  the  application  of  this  rule  results  in  a  conflict  in  the 
selection  of  the  proper  element,  the  specification  relationship  will  take  precedence.  For  example,  an  aircraft’s 
electronic  equipment  typically  has  software  included  in  each  of  the  subsystem  dements.  Software  that  resides 
and  interfaces  with  more  than  one  equipment,  i.e.,  applications  software,  and  overall  system  software  which 
facilitates  the  operation  and  maintenance  of  the  computer  systems  and  associated  programs  (e.g.,  operating 
systems,  compilers,  and  utilities)  will  be  called  out  at  the  appropriate  work  breakdown  level  with  the  program 
(ref.  ANSI/IEEE  Std  610.12  for  definitions  of  applications  and  system  software). 

It  is  incorrect  to  summarize  all  software  on  a  program  or  contract  in  a  work  breakdown  structure  (ref.  Figure 
1-7).  By  separating  these  elements  from  the  hardware  they  support,  performance  measurement  and  management 
control  over  each  equipment  is  difficult  to  mainuin  since  the  true  cost  of  each  equipment  is  not  readily 
available.  Rather  than  a  separate  summarization,  software  should  be  identified  with  the  hardware  it  supports. 
(When  needed,  contractor  management  systems  can  use  an  identifier  for  each  software  element  to  produce 
internal  summaries  for  software  management  purposes.) 

50  4.5.2  Software-Onlv  Contracts.  Separately  contracted  or  stand  alone  software  will  include  the  software, 
data,  services,  facilities  required  to  develop  and  produce  a  software  product  for  a  command  and  control  system, 
radar  system,  information  system,  etc.  Where  software  is  considered  stand  alone  (i.e.,  does  not  reside  or 
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Figure  1-7  COMPARISON  OF  CORRECT  AND  INCORRECT  PROGRAM  WBSs 


MIL-STD-881B 


support  a  specific  equipment,  a  pure  software  upgrade,  etc.),  the  DoD  Component  will  use  the  same  work 
breakdown  structure  format  as  identified  in  Appendix  B,  Electronic/ Automated  Software  Systems,  adjusted  to 
reflect  the  appropriate  levels  of  the  work  breakdown  structure.  Figure  1-9  provides  an  example  of  c  work 
breakdown  structure  for  stand  alone  software. 

50.4.6  WBS  Dictionary.  When  developing  a  program  work  breakdown  structure,  the  DoD  Component  will 
also  develop  a  WBS  Dictionary  (ref.  page  14,  para.  5. 4. 1.1).  The  program  work  breakdown  structure 
dictionary  lists  and  defines  the  work  breakdown  structure  elements,  Although  initially  prepared  for  the  program 
work  breakdown  structure  by  the  DoD  Component,  it  is  expanded  by  the  contractors  as  they  develop  and  extend 
their  contract  work  breakdown  structure.  The  WBS  Dictionary  should  be  based  on  the  generic  definitions  in 
this  standard,  made  to  be  program  specific  to  define  the  products  being  acquired. 

The  dictionaiy  lists  elements  to  show  their  hierarchical  relationship  to  each  other  and  describes  each  work 
breakdown  structure  element  and  the  resources  and  processes  required  to  produce  it;  it  also  provides  a  link  to 
the  detailed  technical  definition  documents.  The  work  breakdown  structure  dictionary  should  be  revised  to 
reflea  changes  and  should  be  maintained  in  a  current  status  throughout  the  life  of  the  program. 

50.4.7  Program  Work  Breakdown  Structure  Approval.  Final  approval  of  the  program  work  breakdown 
structure  is  achieved  through  approval  of  the  CCDR  plan  process.  Changes  may  be  required  due  to  program 
restructuring  or  changes  with  the  way  the  contractor  will  meet  the  technical  requirements  Changes  are 
approved  following  the  CCDR  Plan  procedures  in  DoD  regulations. 

50.5  Preparing  a  Contract  Work  Breakdown  Structure.  The  individual  work  breakdown  structure  elements  will 
be  selected  from  the  program  work  breakdown  structure  by  the  DoD  Component  for  inclusion  in  a  Request  for 
Proposal  (RFP).  This  will  be  accomplished  by  selecting  the  appropriate  program  work  breakdown  structure 
elements  for  the  products  that  will  be  required  by  each  contract.  Contracts  for  WBS  dements  that  arc  at  Level 
3  or  below  in  the  Program  Work  Breakdown  Structure  will  be  moved  to  Level  2  uni  ail  other  applicable  Level 
2  Common  WBS  elements  will  be  included.  The  result  is  the  contract  work  breakdown  structure.  Figure  1-10 
depicts  the  development  and  relationship  of  the  Program  Work  Breakdown  Structure  with  the  Contract  Work 
Breakdown  Structure.  Each  RFP  includes  the  contract  work  breakdown  structure,  and  the  initial  WBS 
Dictionaiy  prepared  by  the  DoD  Component.  The  RFP  should  irntrua  potential  contractors  to  extend  the 
selected  contract  work  breakdown  structure  elements  to  define  the  complete  contract  scope. 

50.5.1  RFP  Solicitation  Requirements.  The  contract  Iidc  items,  configuration  items,  contract  work  statement 
tasks,  contract  specifications,  and  contractor  responses  will  be  reliable  to  the  work  breakdown  structure  to 
enhance  its  effectiveness  in  satisfying  the  objectives  of  the  particular  acquisition.  It  is  important  to  develop  the 
program  work  breakdown  structure  and  the  CCDR  plan  with  the  development  of  the  SOW  so  as  to  form 
consistency  in  document  structure.  When  aggregated  with  the  program  work  breakdown  structure,  the  extended 
contract  work  breakdown  structure  will  form  a  complete  work  breakdown  structure  of  the  program  for  use 
throughout  the  acquisition  cycle. 

50.5.2  Extend  Contract  Work  Breakdown  Structure.  The  Contractor  extends  the  contract  work  breakdown 
structure  in  the  RFP  and  submits  the  complete  contract  work  breakdown  structure  with  its  proposal.  The 
proposal  submitted  should  be  based  on  the  work  breakdown  structure  in  the  RFP.  Contractors  may  suggest 
changes  to  the  RFP  contract  work  breakdown  structure  elements  when  a  change  is  needed  to  meet  an  essential 
requirement  of  the  RFP  or  to  enhance  the  effectiveness  of  the  contract  work  breakdown  stricture  in  satisfying 
program  objectives.  The  contractor  should  extend  the  contract  work  breakdown  structure  to  the  appropriate 
level  which  satisfies  the  critical  visibility  requirements  and  does  not  overburden  the  contractor  management 
system. 
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Figure  1-9.  STAND  ALONE  SOFTWARE 
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50.6  Implementation  nf  Contraa  Work  Breakdown  Structure.  After  contractors  are  selected,  contract  WBSs 
are  negotiated  as  pan  of  contract  negotiations.  The  proposed  contract  work  breakdown  structure  included  in  the 
successful  proposal  serves  as  the  basis  for  negotiating  an  approved  contract  work  breakdown  structure.  The 
contractor  may  have  proposed  alternate  approaches  to  better  accomplish  the  contract  objectives.  The 
alternatives,  if  accepted  by  the  DoD  Component,  may  impact  the  proposed  program  work  breakdown  structure. 
Revisions  will  be  required  to  the  program  work  breakdown  structure  and  the  contract  work  breakdown  structure 
to  reflect  these  changes.  After  adjustments  and  contract  negotiations,  the  elements  selected  for  the  contract  will 
become  the  basis  for  contractor  extension  during  the  contracted  effort.  Ail  extensions  must  sum  to  the  contract 
work  breakdown  structure  reporting  level  in  the  contract, 

50.6.1  Contract  Work  Breakdown  Structure  Ap:  royal  and  Contract  Award.  Following  approval  of  the 
negotiated  contract,  including  the  contract  work  breakdown  structure,  the  contract  is  awarded.  The  contnet 
identifies  the  requirement  for  providing  the  WBS  Dictionary  through  the  contract  data  requirements  list 
(CDRL).  While  strong  efforts  should  be  placed  on  early  and  accurate  work  breakdown  structure  planning,  work 
breakdown  structure  revisions  may  result  from  expansion  or  contraction  of  program/contract  scope  and  the 
movement  of  a  program  through  its  various  stages.  Normally,  changes  to  the  work  breakdown  structure  should 
not  be  made  after  contracts  are  awarded  and  work  is  underway  unless  major  rescoping  of  the  program  occurs. 
Users  of  this  guide  should  understand  that  the  sequence  shown  in  preceding  paragraphs  may  be  iterative  as  the 
program  evolves,  contracts  are  awarded,  and  the  work  effort  progresses  through  major  program  phases. 
Whenever  the  work  breakdown  structure  is  revised,  the  ability  to  crosswalk  and  track  back  to  the  previous  work 
breakdown  structure  must  be  maintained. 

50.6.2  Implementation  with  Subcontractors.  Contractors  may  require  the  use  of  the  work  breakdown  structure 
by  subcontractors  to  permit  fulfillment  of  contractual  requirements  and  provide  adequate  control  of  the 
subcontract.  Such  subcontractors,  whose  wort;  accounts  for  a  major  segment  of  the  subcontracted  portion  of  the 
prime  contract,  will  be  delineated  in  contracts  a!  the  time  of  award.  It  will  be  the  prime  or  associate 
contractor's  responsibility  to  incorporate  into  the  contract  with  the  affected  subcontractors  ihe  work  breakdown 
structure  requirements.  Figure  1-11  provides  an  example  of  a  prime  work  breakdown  structure  and  its 
relationship  to  a  subcontract  work  breakdown  structure. 

50.6.3  Maintain  Contraa  Work  Breakdown  Structure.  The  contractor  maintains  she  contract  work  breakdown 
structure,  including  change  traceability.  Only  DoD  Component  approved  changes  may  be  incorporated  in 
accordance  with  the  contract  terms.  The  contract  will  indicate  the  levels  of  contract  work  breakdown  structure 
at  which  costs  will  be  reported  to  the  government.  Traceability  of  cost  accumulations  will  be  required  to  those 
extended  contract  work  breakdown  structure  levels  which  are  used  by  the  contractor  for  cost  control  purposes. 

In  the  extended  contract  work  breakdown  structure,  consideration  will  be  given  to  the  specific  contractual, 
technical,  and  managerial  requirements  of  the  defense  materiel  item.  The  contractor  has  complete  flexibility  in 
extending  the  contract  work  breakdown  structure  below  the  reporting  requirement  to  reflect  bow  work  is  to  be 
accomplished,  assuming  lower  elements  to  be  meaningful  product  or  management-oriented  lower  indentures  of  a 
higher-level  element. 

50.7  Relationship  with  Contractor  Management  System.  As  the  end  product  is  subdivided  into  smaller 
subproducts  at  lower  work  breakdown  structure  levels,  the  work  effort  required  by  each  element  can  be 
identified  to  functional  organization  units.  At  some  point  within  the  work  breakdown  structure,  the  contractor 
will  assign  management  responsibility  for  technical,  schedule,  and  cost  performance.  The  cost  management 
system  will  provide  the  necessary  visibility  of  the  lower  levels  of  the  work  breakdown  structure  as  it  interfaces 
with  the  organization.  At  the  juncture  of  the  work  breakdown  structure  element  and  organization  unit,  cost 
accounts  are  usually  established  and  perfonaarce  is  planned,  measured,  recorded  and  controlled.  To  do  so,  the 
technical  requirements  for  the  work  and  work  product  must  be  specified,  the  work  scheduled,  budgeted,  and 


PRIME  WBS 


MIL-STD-881B 


1-21 


Figure  Ml.  PRIME  WBS  TO  SUBCONTRACT  WBS 
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performed,  and  product  attainment  of  specified  technical  requirements  verified.  The  responsible  manager  is 
called  a  cost  account  manage; . 

50.7. 1  Contractor  Organizational  Structure.  People  performing  work  are  organized  to  facilitate  effective 
management.  Whether  the  organization  is  designed  along  program,  function,  natural  work  teams  or  matrix 
lines,  the  organizational  structure  reflects  the  way  the  people  who  will  accomplish  the  work  have  been 
organized.  To  assign  specific  work  tasks,  the  organizational  structure  must  be  linked  effectively  with  the  work 
breakdown  structure.  This  linkage  can  occur  at  any  level  of  the  work  breakdown  structure.  Figure  M2  depicts 
the  linkage  between  the  work  breakdown  structure  and  the  contractor’s  organizational  structure. 

50.7.2  Process -Qrienied  Breakdown  Structure,  One  way  to  assess  contractor  performance  is  through  the 
review  of  selected  process  or  subprocess  data.  When  contractors  are  structured  using  Integrated  Product  Teams 
(IPTs)  this  data  is  often  needed  to  guide  and  evaluate  manufacturing  and  other  process  improvement  initiatives. 
Both  development  and  production  activities  have  data  which  can  be  gathered  to  determine  process/subprocess 
improvement.  Figures  M3  mid  1-14  provide  some  examples  of  development  and  production  activities  and  their 
processes.  Figure  M5  depicts  the  linkage  between  the  work  breakdown  structure  and  the  process-oriented 
breakdown  within  the  contractor’s  cost  management  system.  Visibility  to  specific  processes  can  be  attained 
through  job  coding  (.FAB)  without  extending  the  work  breakdown  structure  to  extremely  low  levels. 

50.7.3  Cost  Account  Level.  To  provide  the  responsible  (cost  account)  manager  with  the  technical,  schedule, 
and  cost  information  needed  to  manage  the  organization’s  work  on  the  work  breakdown  structure  element  for 
which  the  manager  is  responsible,  the  management  control  system  must  be  keyed  to  the  same  work  breakdown 
structure  dement  and  organization  unit.  The  appropriate  work  breakdown  structure  level  at  which  a  cost 
account  is  established  is  primarily  a  function  of  the  magnitude  of  the  program  and  the  type  of  product.  The 
responsible  organization  level  is  a  function  of  the  management  span  of  control  and  upper  management's  desire 
to  delegate  technical,  schedule,  and  cost  responsibility  for  product/caatract  work  breakdown  structure  elements 
to  lower  management  levels.  In  identifying  cost  accounts,  the  contractor  must  be  allowed  to  establish 
organizational  responsibilities  at  meaningful  and  appropriate  levels,  otherwise  the  contractor's  existing 
management  control  systems  and  responsibility  assignments  may  be  affected  adversely.  For  example,  when 
software  is  a  major  component  of  cost  and  DoD  wants  it  identified  separately,  care  must  be  taken  to  not 
unnecessarily  complicate  the  contractor  work  breakdown  structure  and  contractor  management  system.  To  meet 
these  needs,  special  reporting  requirements  axe  specified  in  the  SOW.  In  this  example.  Figure  1-16  shows  how 
the  cost  management  system  with  job  coding  (,SW_J  and  the  work  breakdown  structure  can  provide  needed 
detail  and  visibility  without  extending  the  work  breakdown  structure  to  extremely  low  levels. 

Virtually  all  aspects  of  the  contractor’s  management  control  system,  including  technical  definition,  budgets, 
estimates,  schedules,  work  assignments,  accounting,  progress  assessment,  problem  identification,  and  corrective 
actions,  come  together  at  the  cost  account.  Performance  visibility  is  directly  relatable  to  the  level  and  content  of 
the  cost  account.  NAVSO  1-3627,  AFSCP  173-5,  AFCCP  173-5,  AFLCP  173-5,  AMC-P  715-5,  DLAH 
8400.2,  and  DCAA  P7641.47  contains  a  detailed  explanation  of  the  cost  account  and  related  performance 
measurement  concepts. 
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Figure  1-12.  '  RANSLATfON  FROM  FUNCTION  TO  PRODUCT 
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Figure  l-i4.  PRODUCTION  ACTIVITIES  AND  PROCESSES 
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®L're  115  LINKAGE  between  work  breakdown  structure  and  process-oriented  breakdown 
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Figure  1-16.  LINKAGE  BETWEEN  CONTRACTOR  WBF  AND  CONTRACTOR  MANAGEMENT  SYSTEMS 
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